Re: [PATCH] MAINTAINERS: Update my maintainer entries to reorder email addresses
Hi Shuah, Em Fri, 22 May 2020 20:19:28 -0600 Shuah Khan escreveu: > get_maintainer.pl picks only the first email address found in the file. > Reorder my email addresses so it finds my linuxfoundation.org email. Next time someone would run the ordering script again, this patch would need to be re-applied. Instead, why don't you just use a single e-mail at the maintainer's entry and place the other one at the .mailmap file? > > Signed-off-by: Shuah Khan > --- > MAINTAINERS | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index ecc0749810b0..dbad8b18bfe6 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4404,8 +4404,8 @@ F: include/linux/cpuidle.h > > CPU POWER MONITORING SUBSYSTEM > M: Thomas Renninger > -M: Shuah Khan > M: Shuah Khan > +M: Shuah Khan > L: linux...@vger.kernel.org > S: Maintained > F: tools/power/cpupower/ > @@ -9238,8 +9238,8 @@ F: include/uapi/linux/sunrpc/ > F: net/sunrpc/ > > KERNEL SELFTEST FRAMEWORK > -M: Shuah Khan > M: Shuah Khan > +M: Shuah Khan > L: linux-kselft...@vger.kernel.org > S: Maintained > Q: https://patchwork.kernel.org/project/linux-kselftest/list/ > @@ -17484,8 +17484,8 @@ F:drivers/usb/common/usb-otg-fsm.c > > USB OVER IP DRIVER > M: Valentina Manea > -M: Shuah Khan > M: Shuah Khan > +M: Shuah Khan > L: linux-...@vger.kernel.org > S: Maintained > F: Documentation/usb/usbip_protocol.rst Thanks, Mauro
RE: [PATCH v1 0/3] fix macb phy probe failure if phy-reset is not handled
Hello, A gentle reminder. Any suggestions here? BR, Sagar > -Original Message- > From: Sagar Kadam > Sent: Wednesday, May 13, 2020 7:27 PM > To: linux-kernel@vger.kernel.org; linux-ri...@lists.infradead.org; > devicet...@vger.kernel.org; robh...@kernel.org > Cc: pal...@dabbelt.com; Paul Walmsley ; > atish.pa...@wdc.com; Sagar Kadam > Subject: [PATCH v1 0/3] fix macb phy probe failure if phy-reset is not > handled > > HiFive Unleashed is having VSC8541-01 ethernet phy device and requires a > specific reset sequence of 0-1-0-1 in order to use it in unmanaged mode. > This series addresses a corner case where phy reset is not handled by boot > stages prior to linux. > Somewhat similar unreliable phy probe failure was reported and discussed > here [1]. > The macb driver fails to detect the ethernet phy device if the bootloader > doesn't provide a proper reset sequence to the phy device or the phy itself > is in some invalid state. Currently, the FSBL is resetting the phy device, and > so there is no issue observed in the linux network setup. > > The series is based on linux-5.7-rc5. > Patch 1: Add the OUI to the phy dt node to fix issue of missing mdio device > Patch 2 and 3: > Resetting phy needs GPIO support so add to dt and defconfig. > > [1] https://lkml.org/lkml/2018/11/29/154 > > To reproduce the issue: > 1. Comment out VSC8541 reset sequence in fsbl/main.c >from within the freedom-u540-c000-bootloader. > 2. Build and flash fsbl.bin to micro sdcard. > > Boot the board and bootlog will show network setup failure messages as: > > [ 1.069474] libphy: MACB_mii_bus: probed [ 1.073092] mdio_bus > 1009.ethernet-: MDIO device at address 0 > is missing > . > [ 1.979252] macb 1009.ethernet eth0: Could not attach PHY (-19) > > 3. Now apply the series build, and boot kernel. > 4. MACB and VSC8541 driver get successfully probed and the network is set >without any failure. > > > So irrespective of whether the prior stages handle the phy reset sequence, > the probing is successful in both the cases of cold boot and warm boot. > > Change History: > === > V1: > -Ignore 4th patch as suggested and so removed it from the series. > -Verified this series on 5.7-rc5. > > V0: Base RFC patch. Verified on 5.7-rc2 > > > Sagar Shrikant Kadam (3): > dts: phy: fix missing mdio device and probe failure of vsc8541-01 > device > dts: phy: add GPIO number and active state used for phy reset > riscv: defconfig: enable gpio support for HiFive Unleashed > > arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 2 ++ > arch/riscv/configs/defconfig| 2 ++ > 2 files changed, 4 insertions(+) > > -- > 2.7.4
Re: [PATCH 2/2] orangefs: fix double-unlock issue in service_operation().
On Fri, May 22, 2020 at 11:35:51PM -0500, wu000...@umn.edu wrote: > From: Qiushi Wu > > spin_unlock(>lock) is called before calling wake_up_interruptible(). > But spin_unlock() was called again after a call of the function > "wait_for_matching_downcall" failed. Yes, it was. > Fix this issue by remove > the second spin_unlock(). Why is that a bug? That's not an idle question - you could demonstrate that if you had reproduced an unbalanced unlock experimentally, or you could've proven it possible by analysis of the source. The former ought to be clearly reported; the latter... AFAICS, your reasoning is 1) at the time of wait_for_matching_downcall() call the spinlock is not being held, since we'd unlocked it upstream of that call and had done nothing that could have reacquired it. 2) after the return from that function we are doing unlock. That is a bug, because one should not unlock a spinlock that is not locked. The gap in that proof is the unverified assumption that the locking conditions upon return from wait_for_matching_downcall() are the same as upon its call. IF that assumption holds, there is, indeed a bug. Now, a look at the function in question shows * a comment right before it claiming that it " * Returns with op->lock taken.". Which might or might not be correct. * one of the wait_for_completion...() called; that clearly indicates that no spinlocks should be held upon the entry. * unconditional spin_lock(>lock); right after that. * several predicates checked, apparently some debugging output possibly produced and a value returned. The predicates (op_state_service(), op_state_purged()) are clearly locking-neutral - grep shows fs/orangefs/orangefs-kernel.h:154:#define op_state_serviced(op) ((op)->op_state & OP_VFS_STATE_SERVICED) fs/orangefs/orangefs-kernel.h:155:#define op_state_purged(op) ((op)->op_state & OP_VFS_STATE_PURGED) so it's plain arithmetics. The same, of course, applies to comparisons. In other words, the function *does* acquire that spinlock and does not release it, regardless of the value it returns. Which means that your patch would very likely to cause deadlocks.
Re: [PATCH] arm64: dts: qcom: enable pm8150 rtc
On Fri 22 May 21:12 PDT 2020, Jonathan Marek wrote:
> I don't see any reason for it to be disabled by default.
>
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Jonathan Marek
> ---
> arch/arm64/boot/dts/qcom/pm8150.dtsi | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/pm8150.dtsi
> b/arch/arm64/boot/dts/qcom/pm8150.dtsi
> index c0b197458665..b738c263f9d1 100644
> --- a/arch/arm64/boot/dts/qcom/pm8150.dtsi
> +++ b/arch/arm64/boot/dts/qcom/pm8150.dtsi
> @@ -64,8 +64,6 @@ rtc@6000 {
> reg = <0x6000>;
> reg-names = "rtc", "alarm";
> interrupts = <0x0 0x61 0x1 IRQ_TYPE_NONE>;
> -
> - status = "disabled";
> };
>
> pm8150_gpios: gpio@c000 {
> --
> 2.26.1
>
Re: [PATCH] clk: qcom: sm8250 gcc depends on QCOM_GDSC
On Fri 22 May 21:09 PDT 2020, Jonathan Marek wrote: > The driver will always fail to probe without QCOM_GDSC, so select it. > Reviewed-by: Bjorn Andersson Regards, Bjorn > Signed-off-by: Jonathan Marek > --- > drivers/clk/qcom/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig > index 5df110be52c1..59dc0bdafad4 100644 > --- a/drivers/clk/qcom/Kconfig > +++ b/drivers/clk/qcom/Kconfig > @@ -378,6 +378,7 @@ config SM_GCC_8150 > > config SM_GCC_8250 > tristate "SM8250 Global Clock Controller" > + select QCOM_GDSC > help > Support for the global clock controller on SM8250 devices. > Say Y if you want to use peripheral devices such as UART, > -- > 2.26.1 >
Re: arm64: Register modification during syscall entry/exit stop
I got bitten by this again, so I decided to write up a simple example that shows the problem: https://gist.github.com/Keno/cde691b26e32373307fb7449ad305739 This runs the same child twice. First vanilla where it prints "Hello world". The second time, using a textbook ptrace example, to only print "world". The problem here is that by the time the ptracer gets around to restoring the registers, it's no longer in a syscall stop, so the write to x7 does not get ignored and the correct value of x7 gets clobbered. I copied the syscall definition from musl, so the compiler thinks x7 is live, and we can see an assertion. Output on my machine (will depend on compiler version, etc.): ``` $ gcc -g3 -O3 ptrace_lies.c $ ./a.out Hello World World a.out: ptrace_lies.c:49: do_child: Assertion `v3 == values[2]' failed. a.out: ptrace_lies.c:134: main: Assertion `WIFEXITED(status) && WEXITSTATUS(status) == 0' failed. Aborted (core dumped) ``` However, I don't think that whether or not the compiler thinks that x7 is live is the problem here. The problem is entirely that this mechanism prevents the ptracer from precisely controlling the register state. While basic ptracers don't need this feature (strace), more advanced ptracers (think criu, etc.) absolutely do want to precisely control what the register state is. The ptracer I'm working on (https://rr-project.org/) happens to be an extreme case of this, where it wants *bitwise* equivalent register states such that it can run the same code many times and get the exact same results. Also, if the issue was just that the kernel clobbered x7, that would be fine we could deal with that no problem. However, it's much worse than that, because the behavior of the kernel with respect to x7 depends on what kind of ptrace stop we're in and even worse, in some kinds of stop, there's absolutely no way to get at the actual value of x7. > Hmm, does that actually result in the SVC instruction getting inlined? I > think that's quite dangerous, since we document that we can trash the SVE > register state on a system call, for example. I'm also surprised that > the register variables are honoured by compilers if that inlining can occur. I haven't gotten to trying SVE yet, so I appreciate the warning :). That said, deterministic clobbering of registers is fine. Even changing the registers to random junk is fine. We're happy to read those registers through ptrace. The problem here is that the kernel lies about what the contents of the x7 register is and discards any writes to it. I really hope we can come up with a solution here, I'm already dreading the next time I unexpectedly run into this and have to add yet another special case :(. Keno
RE: [PATCH v5 4/6] clocksource/drivers/timer-riscv: Use per-CPU timer interrupt
> -Original Message-
> From: Daniel Lezcano
> Sent: 22 May 2020 18:38
> To: Anup Patel ; Palmer Dabbelt
> ; Paul Walmsley ; Albert
> Ou ; Thomas Gleixner ; Jason
> Cooper ; Marc Zyngier
> Cc: Atish Patra ; Alistair Francis
> ; Anup Patel ; linux-
> ri...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v5 4/6] clocksource/drivers/timer-riscv: Use per-CPU timer
> interrupt
>
> On 21/05/2020 15:32, Anup Patel wrote:
> > Instead of directly calling RISC-V timer interrupt handler from RISC-V
> > local interrupt conntroller driver, this patch implements RISC-V timer
> > interrupt as a per-CPU interrupt using per-CPU APIs of Linux IRQ
> > subsystem.
> >
> > Signed-off-by: Anup Patel
>
> via which tree do you want this patch to be merged ?
What is your suggestion ?
This series is primarily change in arch/riscv and drivers/irqchip.
Regards,
Anup
>
> > ---
> > arch/riscv/include/asm/irq.h | 2 --
> > drivers/clocksource/timer-riscv.c | 30 +++---
> > drivers/irqchip/irq-riscv-intc.c | 8
> > 3 files changed, 27 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/riscv/include/asm/irq.h
> > b/arch/riscv/include/asm/irq.h index a9e5f07a7e9c..9807ad164015 100644
> > --- a/arch/riscv/include/asm/irq.h
> > +++ b/arch/riscv/include/asm/irq.h
> > @@ -10,8 +10,6 @@
> > #include
> > #include
> >
> > -void riscv_timer_interrupt(void);
> > -
> > #include
> >
> > #endif /* _ASM_RISCV_IRQ_H */
> > diff --git a/drivers/clocksource/timer-riscv.c
> > b/drivers/clocksource/timer-riscv.c
> > index c4f15c4068c0..5fb7c5ba5c91 100644
> > --- a/drivers/clocksource/timer-riscv.c
> > +++ b/drivers/clocksource/timer-riscv.c
> > @@ -14,6 +14,9 @@
> > #include
> > #include
> > #include
> > +#include #include
> > + #include
> > #include
> > #include
> >
> > @@ -39,6 +42,7 @@ static int riscv_clock_next_event(unsigned long delta,
> > return 0;
> > }
> >
> > +static unsigned int riscv_clock_event_irq;
> > static DEFINE_PER_CPU(struct clock_event_device, riscv_clock_event) = {
> > .name = "riscv_timer_clockevent",
> > .features = CLOCK_EVT_FEAT_ONESHOT,
> > @@ -74,30 +78,35 @@ static int riscv_timer_starting_cpu(unsigned int cpu)
> > struct clock_event_device *ce = per_cpu_ptr(_clock_event,
> > cpu);
> >
> > ce->cpumask = cpumask_of(cpu);
> > + ce->irq = riscv_clock_event_irq;
> > clockevents_config_and_register(ce, riscv_timebase, 100,
> > 0x7fff);
> >
> > - csr_set(CSR_IE, IE_TIE);
> > + enable_percpu_irq(riscv_clock_event_irq,
> > + irq_get_trigger_type(riscv_clock_event_irq));
> > return 0;
> > }
> >
> > static int riscv_timer_dying_cpu(unsigned int cpu) {
> > - csr_clear(CSR_IE, IE_TIE);
> > + disable_percpu_irq(riscv_clock_event_irq);
> > return 0;
> > }
> >
> > /* called directly from the low-level interrupt handler */ -void
> > riscv_timer_interrupt(void)
> > +static irqreturn_t riscv_timer_interrupt(int irq, void *dev_id)
> > {
> > struct clock_event_device *evdev = this_cpu_ptr(_clock_event);
> >
> > csr_clear(CSR_IE, IE_TIE);
> > evdev->event_handler(evdev);
> > +
> > + return IRQ_HANDLED;
> > }
> >
> > static int __init riscv_timer_init_dt(struct device_node *n) {
> > int cpuid, hartid, error;
> > + struct of_phandle_args oirq;
> >
> > hartid = riscv_of_processor_hartid(n);
> > if (hartid < 0) {
> > @@ -115,6 +124,13 @@ static int __init riscv_timer_init_dt(struct
> device_node *n)
> > if (cpuid != smp_processor_id())
> > return 0;
> >
> > + oirq.np = riscv_of_intc_domain_node();
> > + oirq.args_count = 1;
> > + oirq.args[0] = RV_IRQ_TIMER;
> > + riscv_clock_event_irq = irq_create_of_mapping();
> > + if (!riscv_clock_event_irq)
> > + return -ENODEV;
> > +
> > pr_info("%s: Registering clocksource cpuid [%d] hartid [%d]\n",
> >__func__, cpuid, hartid);
> > error = clocksource_register_hz(_clocksource, riscv_timebase);
> > @@ -126,6 +142,14 @@ static int __init riscv_timer_init_dt(struct
> > device_node *n)
> >
> > sched_clock_register(riscv_sched_clock, 64, riscv_timebase);
> >
> > + error = request_percpu_irq(riscv_clock_event_irq,
> > + riscv_timer_interrupt,
> > + "riscv-timer", _clock_event);
> > + if (error) {
> > + pr_err("registering percpu irq failed [%d]\n", error);
> > + return error;
> > + }
> > +
> > error = cpuhp_setup_state(CPUHP_AP_RISCV_TIMER_STARTING,
> > "clockevents/riscv/timer:starting",
> > riscv_timer_starting_cpu, riscv_timer_dying_cpu); diff
> --git
> > a/drivers/irqchip/irq-riscv-intc.c b/drivers/irqchip/irq-riscv-intc.c
> > index 2f364e6a87f9..d4fbc3543459 100644
> > --- a/drivers/irqchip/irq-riscv-intc.c
> > +++ b/drivers/irqchip/irq-riscv-intc.c
> > @@ -23,20 +23,12 @@ static
Re: [PATCH V4 7/8] fs/ext4: Introduce DAX inode flag
On May 21, 2020, at 1:13 PM, ira.we...@intel.com wrote:
>
> From: Ira Weiny
>
> Add a flag to preserve FS_XFLAG_DAX in the ext4 inode.
>
> Set the flag to be user visible and changeable. Set the flag to be
> inherited. Allow applications to change the flag at any time with the
> exception of if VERITY or ENCRYPT is set.
>
> Disallow setting VERITY or ENCRYPT if DAX is set.
>
> Finally, on regular files, flag the inode to not be cached to facilitate
> changing S_DAX on the next creation of the inode.
>
> Signed-off-by: Ira Weiny
Reviewed-by: Andreas Dilger
>
> ---
> Changes from V3:
> Move bit to bit25 per Andreas
>
> Change from V2:
> Add in making verity and DAX exclusive.
> 'Squash' in making encryption and DAX exclusive.
> Add in EXT4_INODE_DAX flag definition to be compatible with
> ext4_[set|test]_inode_flag() bit operations
> Use ext4_[set|test]_inode_flag() bit operations to be consistent
> with other code.
>
> Change from V0:
> Add FS_DAX_FL to include/uapi/linux/fs.h
> to be consistent
> Move ext4_dax_dontcache() to ext4_ioctl_setflags()
> This ensures that it is only set when the flags are going to be
> set and not if there is an error
> Also this sets don't cache in the FS_IOC_SETFLAGS case
>
> Change from RFC:
> use new d_mark_dontcache()
> Allow caching if ALWAYS/NEVER is set
> Rebased to latest Linus master
> Change flag to unused 0x0100
> update ext4_should_enable_dax()
> ---
> fs/ext4/ext4.h | 14 ++
> fs/ext4/inode.c | 2 +-
> fs/ext4/ioctl.c | 34 +-
> fs/ext4/super.c | 3 +++
> fs/ext4/verity.c| 2 +-
> include/uapi/linux/fs.h | 1 +
> 6 files changed, 49 insertions(+), 7 deletions(-)
>
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index 65ffb831b2b9..09b8906568d2 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -415,13 +415,16 @@ struct flex_groups {
> #define EXT4_VERITY_FL0x0010 /* Verity protected
> inode */
> #define EXT4_EA_INODE_FL 0x0020 /* Inode used for large EA */
> /* 0x0040 was formerly EXT4_EOFBLOCKS_FL */
> +
> +#define EXT4_DAX_FL 0x0200 /* Inode is DAX */
> +
> #define EXT4_INLINE_DATA_FL 0x1000 /* Inode has inline data. */
> #define EXT4_PROJINHERIT_FL 0x2000 /* Create with parents
> projid */
> #define EXT4_CASEFOLD_FL 0x4000 /* Casefolded file */
> #define EXT4_RESERVED_FL 0x8000 /* reserved for ext4 lib */
>
> -#define EXT4_FL_USER_VISIBLE 0x705BDFFF /* User visible flags */
> -#define EXT4_FL_USER_MODIFIABLE 0x604BC0FF /* User modifiable
> flags */
> +#define EXT4_FL_USER_VISIBLE 0x725BDFFF /* User visible flags */
> +#define EXT4_FL_USER_MODIFIABLE 0x624BC0FF /* User modifiable
> flags */
>
> /* Flags we can manipulate with through EXT4_IOC_FSSETXATTR */
> #define EXT4_FL_XFLAG_VISIBLE (EXT4_SYNC_FL | \
> @@ -429,14 +432,16 @@ struct flex_groups {
>EXT4_APPEND_FL | \
>EXT4_NODUMP_FL | \
>EXT4_NOATIME_FL | \
> - EXT4_PROJINHERIT_FL)
> + EXT4_PROJINHERIT_FL | \
> + EXT4_DAX_FL)
>
> /* Flags that should be inherited by new inodes from their parent. */
> #define EXT4_FL_INHERITED (EXT4_SECRM_FL | EXT4_UNRM_FL | EXT4_COMPR_FL |\
> EXT4_SYNC_FL | EXT4_NODUMP_FL | EXT4_NOATIME_FL |\
> EXT4_NOCOMPR_FL | EXT4_JOURNAL_DATA_FL |\
> EXT4_NOTAIL_FL | EXT4_DIRSYNC_FL |\
> -EXT4_PROJINHERIT_FL | EXT4_CASEFOLD_FL)
> +EXT4_PROJINHERIT_FL | EXT4_CASEFOLD_FL |\
> +EXT4_DAX_FL)
>
> /* Flags that are appropriate for regular files (all but dir-specific ones).
> */
> #define EXT4_REG_FLMASK (~(EXT4_DIRSYNC_FL | EXT4_TOPDIR_FL |
> EXT4_CASEFOLD_FL |\
> @@ -488,6 +493,7 @@ enum {
> EXT4_INODE_VERITY = 20, /* Verity protected inode */
> EXT4_INODE_EA_INODE = 21, /* Inode used for large EA */
> /* 22 was formerly EXT4_INODE_EOFBLOCKS */
> + EXT4_INODE_DAX = 25, /* Inode is DAX */
> EXT4_INODE_INLINE_DATA = 28, /* Data in inode. */
> EXT4_INODE_PROJINHERIT = 29, /* Create with parents projid */
> EXT4_INODE_RESERVED = 31, /* reserved for ext4 lib */
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 68fac9289109..778b0dbe3da6 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -4419,7 +4419,7 @@ static bool ext4_should_enable_dax(struct inode *inode)
> if
Re: [GIT PULL] SCSI fixes for 5.7-rc6
The pull request you sent on Fri, 22 May 2020 17:43:40 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e644645abf4788e919beeb97925fb6bf43e890a2 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [git pull] drm fixes for v5.7-rc7
The pull request you sent on Sat, 23 May 2020 06:38:11 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-05-23 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a24deb9d68b423f3e5e190b9836d192ee3e0ff9d Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[PATCH 2/2] orangefs: fix double-unlock issue in service_operation().
From: Qiushi Wu
spin_unlock(>lock) is called before calling wake_up_interruptible().
But spin_unlock() was called again after a call of the function
"wait_for_matching_downcall" failed. Fix this issue by remove
the second spin_unlock().
Signed-off-by: Qiushi Wu
---
fs/orangefs/waitqueue.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/orangefs/waitqueue.c b/fs/orangefs/waitqueue.c
index beafc33d57be..3981507ad920 100644
--- a/fs/orangefs/waitqueue.c
+++ b/fs/orangefs/waitqueue.c
@@ -152,7 +152,6 @@ int service_operation(struct orangefs_kernel_op_s *op,
/* got matching downcall; make sure status is in errno format */
if (!ret) {
- spin_unlock(>lock);
op->downcall.status =
orangefs_normalize_to_errno(op->downcall.status);
ret = op->downcall.status;
--
2.17.1
Re: [PATCH] capabilities: Introduce CAP_RESTORE
On Fri, May 22, 2020 at 09:40:37AM -0700, Casey Schaufler wrote: > On 5/21/2020 10:53 PM, Adrian Reber wrote: > > There are probably a few more things guarded by CAP_SYS_ADMIN required > > to run checkpoint/restore as non-root, > > If you need CAP_SYS_ADMIN anyway you're not gaining anything by > separating out CAP_RESTORE. > > > but by applying this patch I can > > already checkpoint and restore processes as non-root. As there are > > already multiple workarounds I would prefer to do it correctly in the > > kernel to avoid that CRIU users are starting to invent more workarounds. > > You've presented a couple of really inappropriate implementations > that would qualify as workarounds. But the other two are completely > appropriate within the system security policy. They don't "get around" > the problem, they use existing mechanisms as they are intended. > With CAP_CHECKPOINT_RESTORE, we will need to use the same mechanisms. The problem is that CAP_SYS_ADMIN is too wide. If a process has CAP_SYS_ADMIN, it can do a lot of things and the operation of forking a process with a specified pid isn't the most dangerous one in this case. Offten security policies don't allow to grant CAP_SYS_ADMIN to any third-party tools even in non-root user namespaces.
Re: [PATCH 03/29] modpost: add read_text_file() and get_line() helpers
On Wed, May 20, 2020 at 9:29 PM Peter Zijlstra wrote: > > On Wed, May 20, 2020 at 09:17:45PM +0900, Masahiro Yamada wrote: > > > The specification [1] says this: > > > > "The value returned may be less than nbyte if the number of bytes > > left in the file is less than nbyte, if the read() request was > > interrupted by a signal, or if the file is a pipe or FIFO or > > special file and has fewer than nbyte bytes immediately available > > for reading." > > > > > > This case does not meet any of 'if ...' parts. > > So nobody ever ^Z's their build? I really don't think you can assume > that you'll never get a signal. That's just asking for trouble. > > Doing the right thing here is 'trivial', there is absolutely no reason > to not do it. In my testing, read() seems robust against ^Z, but perhaps it might be implementation-defined ? I think you are right. We can gain extra safety with a trivial change. -- Best Regards Masahiro Yamada
[PATCH] drm: fix setting of plane_mask in pan_display_atomic() function for linux-4.4
From: Xuebing Chen The provides drm_for_each_plane_mask macro and plane_mask is defined as bitmask of plane indices, such as 1< --- drivers/gpu/drm/drm_fb_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index e449f22..6a9f7ee 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -1256,7 +1256,7 @@ retry: goto fail; plane = mode_set->crtc->primary; - plane_mask |= drm_plane_index(plane); + plane_mask |= 1 << drm_plane_index(plane); plane->old_fb = plane->fb; } -- 2.7.4
[PATCH] mt76: mt7915: Use proper enum type in __mt7915_mcu_msg_send
Clang warns:
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:232:9: warning: implicit
conversion from enumeration type 'enum mt76_txq_id' to different
enumeration type 'enum mt7915_txq_id' [-Wenum-conversion]
txq = MT_TXQ_FWDL;
~ ^~~
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:239:9: warning: implicit
conversion from enumeration type 'enum mt76_txq_id' to different
enumeration type 'enum mt7915_txq_id' [-Wenum-conversion]
txq = MT_TXQ_MCU_WA;
~ ^
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:243:9: warning: implicit
conversion from enumeration type 'enum mt76_txq_id' to different
enumeration type 'enum mt7915_txq_id' [-Wenum-conversion]
txq = MT_TXQ_MCU;
~ ^~
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:287:36: warning:
implicit conversion from enumeration type 'enum mt7915_txq_id' to
different enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
return mt76_tx_queue_skb_raw(dev, txq, skb, 0);
~~~^~~~
txq should be a "enum mt76_txq_id" as values of that type are the only
ones assigned to it and that is the type that mt76_tx_queue_skb_raw
expects.
Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets")
Link: https://github.com/ClangBuiltLinux/linux/issues/1035
Signed-off-by: Nathan Chancellor
---
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
index f00ad2b66761..916f664e964e 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
@@ -220,7 +220,7 @@ static int __mt7915_mcu_msg_send(struct mt7915_dev *dev,
struct sk_buff *skb,
{
struct mt7915_mcu_txd *mcu_txd;
u8 seq, pkt_fmt, qidx;
- enum mt7915_txq_id txq;
+ enum mt76_txq_id txq;
__le32 *txd;
u32 val;
base-commit: c11d28ab4a691736e30b49813fb801847bd44e83
--
2.27.0.rc0
Re: Re: [PATCH v12 00/18] Enable FSGSBASE instructions
> Setting the fs register in userspace is an essential feature for running > legacy code in SGX. We have been following LKML discussions on this > instruction for years, and hoping this feature would be supported by Linux, If you need a feature you should comment on it. One of the reasons it took so long is that the users didn't speak up. -Andi
[PATCH] drm: fix setting of plane_mask in pan_display_atomic() function for linux-4.4
From: Xuebing Chen The provides drm_for_each_plane_mask macro and plane_mask is defined as bitmask of plane indices, such as 1< --- drivers/gpu/drm/drm_fb_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index e449f22..6a9f7ee 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -1256,7 +1256,7 @@ retry: goto fail; plane = mode_set->crtc->primary; - plane_mask |= drm_plane_index(plane); + plane_mask |= 1 << drm_plane_index(plane); plane->old_fb = plane->fb; } -- 2.7.4
[RFC PATCH 1/1] usb: dwc3: of-simple: Add extcon support
Add optional extcon notifier support to enable the hotplug / unplug of
the underlying PHY layer devices.
If supported, the Device Tree (DT) node for the device should include an
"extcon" property which is a phandle to an extcon DT node.
This patch is an effort to incorporate the equivalent support from the
Rockchip dwc3 driver implementation from Chrome OS [1] to the mainline.
[1] : https://chromium.googlesource.com/chromiumos/third_party/kernel/
+/refs/heads/chromeos-4.4/drivers/usb/dwc3/dwc3-rockchip.c
Cc: Benson Leung
Cc: Guenter Roeck
Cc: Enric Balletbo i Serra
Signed-off-by: Prashant Malani
---
drivers/usb/dwc3/dwc3-of-simple.c | 149 +-
1 file changed, 146 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-of-simple.c
b/drivers/usb/dwc3/dwc3-of-simple.c
index e64754be47b4..28bde27cd1f9 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -11,6 +11,7 @@
* by Subbaraya Sundeep Bhatta
*/
+#include
#include
#include
#include
@@ -29,8 +30,117 @@ struct dwc3_of_simple {
struct reset_control*resets;
boolpulse_resets;
boolneed_reset;
+ struct extcon_dev *edev;
+ struct notifier_block nb;
+ struct work_struct work;
+ /* Denotes whether child devices have been populated. */
+ boolpopulated;
+ boolsuspended;
+ spinlock_t suspend_lock;
};
+static int dwc3_of_simple_populate(struct dwc3_of_simple *simple)
+{
+ struct device *dev = simple->dev;
+ struct device_node *np = dev->of_node;
+ int ret;
+
+ ret = of_platform_populate(np, NULL, NULL, dev);
+ if (ret) {
+ dev_err(dev, "Failed to populate dwc3 devices.\n");
+ return ret;
+ }
+ simple->populated = true;
+ return 0;
+}
+
+static void dwc3_of_simple_depopulate(struct dwc3_of_simple *simple)
+{
+ if (simple->populated) {
+ of_platform_depopulate(simple->dev);
+ simple->populated = false;
+ }
+}
+
+static void dwc3_of_simple_work(struct work_struct *work)
+{
+ struct dwc3_of_simple *simple = container_of(work,
+ struct dwc3_of_simple, work);
+ struct extcon_dev *edev = simple->edev;
+
+ if (extcon_get_state(edev, EXTCON_USB_HOST) > 0) {
+ if (simple->populated)
+ return;
+
+ dwc3_of_simple_populate(simple);
+ } else {
+ if (!simple->populated)
+ return;
+
+ dwc3_of_simple_depopulate(simple);
+ }
+}
+
+static int dwc3_of_simple_notifier(struct notifier_block *nb,
+ unsigned long event, void *ptr)
+{
+ struct dwc3_of_simple *simple = container_of(nb, struct dwc3_of_simple,
+ nb);
+ unsigned long flags;
+
+ spin_lock_irqsave(>suspend_lock, flags);
+ if (!simple->suspended)
+ schedule_work(>work);
+ spin_unlock_irqrestore(>suspend_lock, flags);
+
+ return NOTIFY_OK;
+}
+
+static int dwc3_of_simple_extcon_register(struct dwc3_of_simple *simple)
+{
+ struct device *dev = simple->dev;
+ struct extcon_dev *edev;
+ int ret;
+
+ edev = extcon_get_edev_by_phandle(dev, 0);
+ if (IS_ERR(edev)) {
+ /* The extcon property is optional. */
+ if (PTR_ERR(edev) == -ENODEV)
+ return 0;
+ if (PTR_ERR(edev) != -EPROBE_DEFER)
+ dev_err(dev, "Couldn't get extcon device.\n");
+ return PTR_ERR(edev);
+ }
+
+ INIT_WORK(>work, dwc3_of_simple_work);
+
+ simple->nb.notifier_call = dwc3_of_simple_notifier;
+ ret = devm_extcon_register_notifier(dev, edev, EXTCON_USB_HOST,
+ >nb);
+ if (ret < 0) {
+ dev_err(dev, "Failed to register notifier.\n");
+ return ret;
+ }
+
+ simple->edev = edev;
+
+ return 0;
+}
+
+static void dwc3_of_simple_extcon_unregister(struct dwc3_of_simple *simple)
+{
+ if (!simple->edev)
+ return;
+
+ /*
+* We explicitly unregister the notifier to prevent races with
+* the of_depopulate() call in remove().
+*/
+ devm_extcon_unregister_notifier(simple->dev, simple->edev,
+ EXTCON_USB_HOST, >nb);
+ cancel_work_sync(>work);
+}
+
static int dwc3_of_simple_probe(struct platform_device *pdev)
{
struct dwc3_of_simple *simple;
@@ -47,6 +157,8 @@ static int dwc3_of_simple_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, simple);
simple->dev = dev;
+ spin_lock_init(>suspend_lock);
+
[PATCH] arm64: dts: qcom: enable pm8150 rtc
I don't see any reason for it to be disabled by default.
Signed-off-by: Jonathan Marek
---
arch/arm64/boot/dts/qcom/pm8150.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/pm8150.dtsi
b/arch/arm64/boot/dts/qcom/pm8150.dtsi
index c0b197458665..b738c263f9d1 100644
--- a/arch/arm64/boot/dts/qcom/pm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150.dtsi
@@ -64,8 +64,6 @@ rtc@6000 {
reg = <0x6000>;
reg-names = "rtc", "alarm";
interrupts = <0x0 0x61 0x1 IRQ_TYPE_NONE>;
-
- status = "disabled";
};
pm8150_gpios: gpio@c000 {
--
2.26.1
[RFC PATCH 0/1] usb: dwc3: Extcon hotplug support to of-simple
Some platforms like rk3399 would like to power on the USB PHY layer only when external devices are connected. This patch introduces optional support for extcon USB_HOST events, so that child devices are populated/depopulated when external devices are connected/disconnected, respectively. This is also useful since some PHY drivers like phy-rockchip-typec only configure their Type C Phy on power on; if they are only powered on once at boot by dwc3, these drivers will not be able to reconfigure their PHY for peripherals plugged in later, like (Display Port) DP monitors. I thought I’d send out an initial RFC patch, for comments and feedback about the approach. Depending on feedback, we can refine this approach and modify the bindings file. Thanks, Prashant Malani (1): usb: dwc3: of-simple: Add extcon support drivers/usb/dwc3/dwc3-of-simple.c | 149 +- 1 file changed, 146 insertions(+), 3 deletions(-) -- 2.27.0.rc0.183.gde8f92d652-goog
Re: [RFC][PATCH 0/2] Add support for using reserved memory for ima buffer pass
Hello Prakhar, Prakhar Srivastava writes: > On 5/12/20 4:05 PM, Rob Herring wrote: >> On Wed, May 06, 2020 at 10:50:04PM -0700, Prakhar Srivastava wrote: >>> Hi Mark, >> >> Please don't top post. >> >>> This patch set currently only address the Pure DT implementation. >>> EFI and ACPI implementations will be posted in subsequent patchsets. >>> >>> The logs are intended to be carried over the kexec and once read the >>> logs are no longer needed and in prior conversation with James( >>> https://lore.kernel.org/linux-arm-kernel/0053eb68-0905-4679-c97a-00c5cb6f1...@arm.com/) >>> the apporach of using a chosen node doesn't >>> support the case. >>> >>> The DT entries make the reservation permanent and thus doesnt need kernel >>> segments to be used for this, however using a chosen-node with >>> reserved memory only changes the node information but memory still is >>> reserved via reserved-memory section. >> >> I think Mark's point was whether it needs to be permanent. We don't >> hardcode the initrd address for example. >> > Thankyou for clarifying my misunderstanding, i am modelling this keeping to > the > TPM log implementation that uses a reserved memory. I will rev up the version > with chosen-node support. > That will make the memory reservation free after use. Nice. Do you intend to use the same property that powerpc uses (linux,ima-kexec-buffer)? >>> On 5/5/20 2:59 AM, Mark Rutland wrote: Hi Prakhar, On Mon, May 04, 2020 at 01:38:27PM -0700, Prakhar Srivastava wrote: > IMA during kexec(kexec file load) verifies the kernel signature and > measures >> >> What's IMAIMA is a LSM attempting to detect if files have been accidentally >> or > maliciously altered, both remotely and locally, it can also be used > to appraise a file's measurement against a "good" value stored as an extended > attribute, and enforce local file integrity. > > IMA also validates and measures the signers of the kernel and initrd > during kexec. The measurements are extended to PCR 10(configurable) and the > logs > stored in memory, however once kexec'd the logs are lost. Kexec is used as > secondary boot loader in may use cases and loosing the signer > creates a security hole. > > This patch is an implementation to carry over the logs and making it > possible to remotely validate the signers of the kernel and initrd. Such a > support exits only in powerpc. > This patch makes the carry over of logs architecture independent and puts the > complexity in a driver. If I'm not mistaken, the code at arch/powerpc/kexec/ima.c isn't actually powerpc-specific. It could be moved to an arch-independent directory and used by any other architecture which supports device trees. I think that's the simplest way forward. And to be honest I'm still trying to understand why you didn't take that approach. Did you try it and hit some obstacle or noticed a disadvantage for your use case? -- Thiago Jung Bauermann IBM Linux Technology Center
[PATCH] clk: qcom: sm8250 gcc depends on QCOM_GDSC
The driver will always fail to probe without QCOM_GDSC, so select it. Signed-off-by: Jonathan Marek --- drivers/clk/qcom/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig index 5df110be52c1..59dc0bdafad4 100644 --- a/drivers/clk/qcom/Kconfig +++ b/drivers/clk/qcom/Kconfig @@ -378,6 +378,7 @@ config SM_GCC_8150 config SM_GCC_8250 tristate "SM8250 Global Clock Controller" + select QCOM_GDSC help Support for the global clock controller on SM8250 devices. Say Y if you want to use peripheral devices such as UART, -- 2.26.1
Re: [PATCH] ovl: make private mounts longterm
On Fri, May 22, 2020 at 9:56 PM Al Viro wrote: > > On Fri, May 22, 2020 at 08:53:49PM +0200, Miklos Szeredi wrote: > > Right, we should just get rid of ofs->upper_mnt and ofs->upperdir_trap > > and use ofs->layers[0] to store those. > > For that you'd need to allocate ->layers before you get to ovl_get_upper(), > though. I'm not saying it's a bad idea - doing plain memory allocations > before anything else tends to make failure exits cleaner; it's just that > it'll take some massage. Basically, do ovl_split_lowerdirs() early, > then allocate everything you need, then do lookups, etc., filling that > stuff. That was exactly the plan I set out. > Regarding this series - the points regarding the name choice and the > need to document the calling conventions change still remain. Agreed. Thanks, Miklos
[PATCH] usb: gadget: fix potential double-free in m66592_probe.
From: Qiushi Wu
m66592_free_request() is called under label "err_add_udc"
and "clean_up", and m66592->ep0_req is not set to NULL after
first free, leading to a double-free. Fix this issue by
setting m66592->ep0_req to NULL after the first free.
Fixes: 0f91349b89f3 ("usb: gadget: convert all users to the new udc
infrastructure")
Signed-off-by: Qiushi Wu
---
drivers/usb/gadget/udc/m66592-udc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/m66592-udc.c
b/drivers/usb/gadget/udc/m66592-udc.c
index 75d16a8902e6..931e6362a13d 100644
--- a/drivers/usb/gadget/udc/m66592-udc.c
+++ b/drivers/usb/gadget/udc/m66592-udc.c
@@ -1667,7 +1667,7 @@ static int m66592_probe(struct platform_device *pdev)
err_add_udc:
m66592_free_request(>ep[0].ep, m66592->ep0_req);
-
+ m66592->ep0_req = NULL;
clean_up3:
if (m66592->pdata->on_chip) {
clk_disable(m66592->clk);
--
2.17.1
[PATCH v2] orangefs: convert get_user_pages() --> pin_user_pages()
This code was using get_user_pages*(), in a "Case 1" scenario
(Direct IO), using the categorization from [1]. That means that it's
time to convert the get_user_pages*() + put_page() calls to
pin_user_pages*() + unpin_user_pages() calls.
There is some helpful background in [2]: basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
Cc: Mike Marshall
Cc: Martin Brandenburg
Cc: de...@lists.orangefs.org
Cc: linux-fsde...@vger.kernel.org
Signed-off-by: John Hubbard
---
Hi,
Note that I have only compile-tested this patch, although that does
also include cross-compiling for a few other arches.
Changes since v1 [3]: correct the commit description, so that
it refers to "Case 1" instead of "Case 2".
[3] https://lore.kernel.org/r/20200518060139.2828423-1-jhubb...@nvidia.com
thanks,
John Hubbard
NVIDIA
fs/orangefs/orangefs-bufmap.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/fs/orangefs/orangefs-bufmap.c b/fs/orangefs/orangefs-bufmap.c
index 2bb916d68576..538e839590ef 100644
--- a/fs/orangefs/orangefs-bufmap.c
+++ b/fs/orangefs/orangefs-bufmap.c
@@ -168,10 +168,7 @@ static DEFINE_SPINLOCK(orangefs_bufmap_lock);
static void
orangefs_bufmap_unmap(struct orangefs_bufmap *bufmap)
{
- int i;
-
- for (i = 0; i < bufmap->page_count; i++)
- put_page(bufmap->page_array[i]);
+ unpin_user_pages(bufmap->page_array, bufmap->page_count);
}
static void
@@ -268,7 +265,7 @@ orangefs_bufmap_map(struct orangefs_bufmap *bufmap,
int offset = 0, ret, i;
/* map the pages */
- ret = get_user_pages_fast((unsigned long)user_desc->ptr,
+ ret = pin_user_pages_fast((unsigned long)user_desc->ptr,
bufmap->page_count, FOLL_WRITE,
bufmap->page_array);
if (ret < 0)
@@ -280,7 +277,7 @@ orangefs_bufmap_map(struct orangefs_bufmap *bufmap,
for (i = 0; i < ret; i++) {
SetPageError(bufmap->page_array[i]);
- put_page(bufmap->page_array[i]);
+ unpin_user_page(bufmap->page_array[i]);
}
return -ENOMEM;
}
--
2.26.2
[PATCH] phy: intel: Eliminate unnecessary assignment in intel_cbphy_set_mode
Clang warns:
drivers/phy/intel/phy-intel-combo.c:202:34: warning: implicit conversion
from enumeration type 'enum intel_phy_mode' to different enumeration
type 'enum intel_combo_mode' [-Wenum-conversion]
enum intel_combo_mode cb_mode = PHY_PCIE_MODE;
~~~ ^
1 warning generated.
The correct enum to use would be PCIE0_PCIE1_MODE. However, eliminating
this assignment is a little better because the switch statement always
assigns a new value to cb_mode, which also takes care of the warning.
Fixes: ac0a95a3ea78 ("phy: intel: Add driver support for ComboPhy")
Link: https://github.com/ClangBuiltLinux/linux/issues/1034
Signed-off-by: Nathan Chancellor
---
drivers/phy/intel/phy-intel-combo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/intel/phy-intel-combo.c
b/drivers/phy/intel/phy-intel-combo.c
index c2a35be4cdfb..4bc1276ecf23 100644
--- a/drivers/phy/intel/phy-intel-combo.c
+++ b/drivers/phy/intel/phy-intel-combo.c
@@ -199,9 +199,9 @@ static int intel_cbphy_pcie_dis_pad_refclk(struct
intel_cbphy_iphy *iphy)
static int intel_cbphy_set_mode(struct intel_combo_phy *cbphy)
{
- enum intel_combo_mode cb_mode = PHY_PCIE_MODE;
enum aggregated_mode aggr = cbphy->aggr_mode;
struct device *dev = cbphy->dev;
+ enum intel_combo_mode cb_mode;
enum intel_phy_mode mode;
int ret;
base-commit: c11d28ab4a691736e30b49813fb801847bd44e83
--
2.27.0.rc0
mmotm 2020-05-22-20-35 uploaded
The mm-of-the-moment snapshot 2020-05-22-20-35 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (5.x or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. https://github.com/hnaz/linux-mm The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is also available at https://github.com/hnaz/linux-mm This mmotm tree contains the following patches against 5.7-rc6: (patches marked "*" will be included in linux-next) origin.patch * device-dax-dont-leak-kernel-memory-to-user-space-after-unloading-kmem.patch * x86-bitops-fix-build-regression.patch * rapidio-fix-an-error-in-get_user_pages_fast-error-handling.patch * selftests-vm-gitignore-add-mremap_dontunmap.patch * selftests-vm-write_to_hugetlbfsc-fix-unused-variable-warning.patch * kasan-disable-branch-tracing-for-core-runtime.patch * kasan-disable-branch-tracing-for-core-runtime-v2.patch * sh-include-linux-time_typesh-for-sockios.patch * maintainers-update-email-address-for-naoya-horiguchi.patch * sparc32-use-pud-rather-than-pgd-to-get-pmd-in-srmmu_nocache_init.patch * z3fold-fix-use-after-free-when-freeing-handles.patch * maintainers-add-files-related-to-kdump.patch * checkpatch-test-git_dir-changes.patch * proc-kpageflags-prevent-an-integer-overflow-in-stable_page_flags.patch * proc-kpageflags-do-not-use-uninitialized-struct-pages.patch * kcov-cleanup-debug-messages.patch * kcov-fix-potential-use-after-free-in-kcov_remote_start.patch * kcov-move-t-kcov-assignments-into-kcov_start-stop.patch * kcov-move-t-kcov_sequence-assignment.patch * kcov-use-t-kcov_mode-as-enabled-indicator.patch * kcov-collect-coverage-from-interrupts.patch * usb-core-kcov-collect-coverage-from-usb-complete-callback.patch * memcg-optimize-memorynuma_stat-like-memorystat.patch * lib-lzo-fix-ambiguous-encoding-bug-in-lzo-rle.patch * mm-compaction-avoid-vm_bug_onpageslab-in-page_mapcount.patch * x86-mm-ptdump-calculate-effective-permissions-correctly.patch * mm-ptdump-expand-type-of-val-in-note_page.patch * mm-z3fold-silence-kmemleak-false-positives-of-slots.patch * squashfs-migrate-from-ll_rw_block-usage-to-bio.patch * squashfs-migrate-from-ll_rw_block-usage-to-bio-fix.patch * ocfs2-add-missing-annotation-for-dlm_empty_lockres.patch * ocfs2-mount-shared-volume-without-ha-stack.patch * arch-parisc-include-asm-pgtableh-remove-unused-old_pte.patch * drivers-tty-serial-sh-scic-suppress-uninitialized-var-warning.patch * ramfs-support-o_tmpfile.patch * vfs-track-per-sb-writeback-errors-and-report-them-to-syncfs.patch * buffer-record-blockdev-write-errors-in-super_block-that-it-backs.patch * kernel-watchdog-flush-all-printk-nmi-buffers-when-hardlockup-detected.patch mm.patch * usercopy-mark-dma-kmalloc-caches-as-usercopy-caches.patch * mm-slub-fix-corrupted-freechain-in-deactivate_slab.patch * mm-slub-fix-corrupted-freechain-in-deactivate_slab-fix.patch * slub-remove-userspace-notifier-for-cache-add-remove.patch * slub-remove-kmalloc-under-list_lock-from-list_slab_objects.patch * mm-slub-fix-stack-overruns-with-slub_stats.patch * mm-slub-add-panic_on_error-to-the-debug-facilities-fix.patch * mm-dump_page-do-not-crash-with-invalid-mapping-pointer.patch * mm-move-readahead-prototypes-from-mmh.patch * mm-return-void-from-various-readahead-functions.patch * mm-ignore-return-value-of-readpages.patch * mm-move-readahead-nr_pages-check-into-read_pages.patch * mm-add-new-readahead_control-api.patch * mm-use-readahead_control-to-pass-arguments.patch * mm-rename-various-offset-parameters-to-index.patch * mm-rename-readahead-loop-variable-to-i.patch * mm-remove-page_offset-from-readahead-loop.patch * mm-put-readahead-pages-in-cache-earlier.patch * mm-add-readahead-address-space-operation.patch * mm-move-end_index-check-out-of-readahead-loop.patch * mm-add-page_cache_readahead_unbounded.patch *
Re: [PATCH 2/3] gpio: pxa: Fix return value of pxa_gpio_probe()
On 05/23/2020 03:07 AM, Robert Jarzmik wrote:
Tiezhu Yang writes:
When call function devm_platform_ioremap_resource(), we should use IS_ERR()
to check the return value and return PTR_ERR() if failed.
Fixes: 542c25b7a209 ("drivers: gpio: pxa: use devm_platform_ioremap_resource()")
Signed-off-by: Tiezhu Yang
---
drivers/gpio/gpio-pxa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-pxa.c b/drivers/gpio/gpio-pxa.c
index 1361270..0cb6600 100644
--- a/drivers/gpio/gpio-pxa.c
+++ b/drivers/gpio/gpio-pxa.c
@@ -660,8 +660,8 @@ static int pxa_gpio_probe(struct platform_device *pdev)
pchip->irq1 = irq1;
gpio_reg_base = devm_platform_ioremap_resource(pdev, 0);
- if (!gpio_reg_base)
- return -EINVAL;
+ if (IS_ERR(gpio_reg_base))
+ return PTR_ERR(gpio_reg_base);
As far as I know, devm_platform_ioremap_resource() could return NULL which is
not handled by this test (unless __devm_ioremap() semantics changed since I had
a look).
Hi Robert,
In the function __devm_ioremap_resource(), if __devm_ioremap returns NULL,
it will return IOMEM_ERR_PTR(-ENOMEM).
devm_platform_ioremap_resource()
devm_ioremap_resource()
__devm_ioremap_resource()
__devm_ioremap()
static void __iomem *
__devm_ioremap_resource(struct device *dev, const struct resource *res,
enum devm_ioremap_type type)
{
...
dest_ptr = __devm_ioremap(dev, res->start, size, type);
if (!dest_ptr) {
dev_err(dev, "ioremap failed for resource %pR\n", res);
devm_release_mem_region(dev, res->start, size);
dest_ptr = IOMEM_ERR_PTR(-ENOMEM);
}
return dest_ptr;
}
And also, we can see the comment of devm_ioremap_resource():
Usage example:
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(>dev, res);
if (IS_ERR(base))
return PTR_ERR(base);
Therefore, this patch is incorrect, or rather incomplete.
So I think this patch is correct, do I miss something?
Thanks,
Tiezhu Yang
Cheers.
[PATCH] platform/chrome: fix a double-unlock issue
From: Qiushi Wu
In function cros_ec_ishtp_probe(), "up_write" is already called
before function "cros_ec_dev_init". But "up_write" will be called
again after the calling of the function "cros_ec_dev_init" failed.
Thus add a call of the function “down_write” in this if branch
for the completion of the exception handling.
Fixes: 26a14267aff2 ("platform/chrome: Add ChromeOS EC ISHTP driver")
Signed-off-by: Qiushi Wu
---
drivers/platform/chrome/cros_ec_ishtp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/chrome/cros_ec_ishtp.c
b/drivers/platform/chrome/cros_ec_ishtp.c
index 93a71e93a2f1..41d60af618c9 100644
--- a/drivers/platform/chrome/cros_ec_ishtp.c
+++ b/drivers/platform/chrome/cros_ec_ishtp.c
@@ -660,8 +660,10 @@ static int cros_ec_ishtp_probe(struct ishtp_cl_device
*cl_device)
/* Register croc_ec_dev mfd */
rv = cros_ec_dev_init(client_data);
- if (rv)
+ if (rv) {
+ down_write(_lock);
goto end_cros_ec_dev_init_error;
+ }
return 0;
--
2.17.1
[PATCH] RDMA: fix missing pci disable in pvrdma_pci_probe()
From: Qiushi Wu
In function pvrdma_pci_probe(), pdev was not disabled in one error
path. Thus replace the jump target “err_free_device” by
"err_disable_pdev".
Fixes: 29c8d9eba550 ("IB: Add vmw_pvrdma driver")
Signed-off-by: Qiushi Wu
---
drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
index e580ae9cc55a..780fd2dfc07e 100644
--- a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
+++ b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
@@ -829,7 +829,7 @@ static int pvrdma_pci_probe(struct pci_dev *pdev,
!(pci_resource_flags(pdev, 1) & IORESOURCE_MEM)) {
dev_err(>dev, "PCI BAR region not MMIO\n");
ret = -ENOMEM;
- goto err_free_device;
+ goto err_disable_pdev;
}
ret = pci_request_regions(pdev, DRV_NAME);
--
2.17.1
Re: [PATCH] x86/mm/init: Stop printing pgt_buf addresses
On Fri, 2020-05-22 at 21:51 -0400, Arvind Sankar wrote:
> On Sat, Feb 29, 2020 at 06:11:20PM -0500, Arvind Sankar wrote:
> > This currently leaks kernel physical addresses into userspace.
> >
> > Signed-off-by: Arvind Sankar
> > ---
> > arch/x86/mm/init.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> > index e7bb483557c9..dc4711f09cdc 100644
> > --- a/arch/x86/mm/init.c
> > +++ b/arch/x86/mm/init.c
> > @@ -121,8 +121,6 @@ __ref void *alloc_low_pages(unsigned int num)
> > } else {
> > pfn = pgt_buf_end;
> > pgt_buf_end += num;
> > - printk(KERN_DEBUG "BRK [%#010lx, %#010lx] PGTABLE\n",
> > - pfn << PAGE_SHIFT, (pgt_buf_end << PAGE_SHIFT) - 1);
> > }
> >
> > for (i = 0; i < num; i++) {
> > --
> > 2.24.1
> >
>
> Ping.
>
> https://lore.kernel.org/lkml/20200229231120.1147527-1-nived...@alum.mit.edu/
If this output is at all valuable,
perhaps emit them as hashed pointers?
Maybe:
---
arch/x86/mm/init.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 1bba16c5742b..44f0d6592c7e 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -121,8 +121,9 @@ __ref void *alloc_low_pages(unsigned int num)
} else {
pfn = pgt_buf_end;
pgt_buf_end += num;
- printk(KERN_DEBUG "BRK [%#010lx, %#010lx] PGTABLE\n",
- pfn << PAGE_SHIFT, (pgt_buf_end << PAGE_SHIFT) - 1);
+ printk(KERN_DEBUG "BRK [0x%8p, 0x%8p] PGTABLE\n",
+ (void *)(pfn << PAGE_SHIFT),
+ (void *)((pgt_buf_end << PAGE_SHIFT) - 1));
}
for (i = 0; i < num; i++) {
Re: [patch V6 00/37] x86/entry: Rework leftovers and merge plan
On Tue, May 19, 2020 at 5:04 PM Peter Zijlstra wrote:
> +#ifdef CONFIG_DEBUG_ENTRY
> /* Begin/end of an instrumentation safe region */
> -#define instrumentation_begin() ({
> \
> +#define instrumentation_begin() ({ \
> asm volatile("%c0:\n\t" \
> ".pushsection .discard.instr_begin\n\t"\
> ".long %c0b - .\n\t" \
> ".popsection\n\t" : : "i" (__COUNTER__)); \
> })
>
> -#define instrumentation_end() ({
> \
> - asm volatile("%c0:\n\t" \
> +/*
> + * Because instrumentation_{begin,end}() can nest, objtool validation
> considers
> + * _begin() a +1 and _end() a -1 and computes a sum over the instructions.
> + * When the value is greater than 0, we consider instrumentation allowed.
> + *
> + * There is a problem with code like:
> + *
> + * noinstr void foo()
> + * {
> + * instrumentation_begin();
> + * ...
> + * if (cond) {
> + * instrumentation_begin();
> + * ...
> + * instrumentation_end();
> + * }
> + * bar();
> + * instrumentation_end();
> + * }
> + *
> + * If instrumentation_end() would be an empty label, like all the other
> + * annotations, the inner _end(), which is at the end of a conditional block,
> + * would land on the instruction after the block.
> + *
> + * If we then consider the sum of the !cond path, we'll see that the call to
> + * bar() is with a 0-value, even though, we meant it to happen with a
> positive
> + * value.
> + *
> + * To avoid this, have _end() be a NOP instruction, this ensures it will be
> + * part of the condition block and does not escape.
> + */
> +#define instrumentation_end() ({ \
> + asm volatile("%c0: nop\n\t" \
> ".pushsection .discard.instr_end\n\t" \
> ".long %c0b - .\n\t" \
> ".popsection\n\t" : : "i" (__COUNTER__)); \
> })
Hello,
I, who don't know how does the objtool handle it, am just curious.
_begin() and _end() are symmetrical, which means if _end() (without nop)
can escape, so can _begin() in a reverse way. For example:
noinstr void foo()
{
instrumentation_begin();
do {
instrumentation_begin();
...
instrumentation_end();
} while (cond);
bar();
instrumentation_end();
}
Here, the first _begin() can be "dragged" into the do-while block.
Expectedly, objtool validation should not complain here.
But objtool validation's not complaining means it can handle it
magically correctly (by distinguishing how many _begin()s should
be taken around the jmp target when jmp in a specific path), or
handle it by not checking if all paths have the same count onto
a jmp target (a little nervous to me), or other possible ways.
Sorry for my curiosity.
Thanks
Lai.
Re: Re: [PATCH] extcon: arizona: Fix runtime PM imbalance on error
> On Fri, May 22, 2020 at 07:07:31PM +0800, Dinghao Liu wrote: > > When arizona_request_irq() returns an error code, a > > pairing runtime PM usage counter decrement is needed > > to keep the counter balanced. For error paths after > > this function, things are the same. > > > > Signed-off-by: Dinghao Liu > > --- > > Good spot on the bug thank you. > > > drivers/extcon/extcon-arizona.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/extcon/extcon-arizona.c > > b/drivers/extcon/extcon-arizona.c > > index 7401733db08b..470bbc8e5089 100644 > > --- a/drivers/extcon/extcon-arizona.c > > +++ b/drivers/extcon/extcon-arizona.c > > @@ -1744,6 +1744,7 @@ static int arizona_extcon_probe(struct > > platform_device *pdev) > > err_rise: > > arizona_free_irq(arizona, jack_irq_rise, info); > > err_gpio: > > + pm_runtime_put(>dev); > > However, I don't think this works as a fix. Firstly, the err_gpio > label is used before the call to pm_runtime_get_sync, this might > be ok since pm_runtime_enable hasn't been called yet but probably > better to add a new label for it. > You are right, thank you for your correction! > Secondly, following the err_hpdet error path will also result in > a double put. In that case I don't think there is any reason why > we need to put before calling input_device_register so it might > just be simplest to move that put until after registering the > input device. > Agree. I will fix this in the next edition of patch. Regards, Dinghao > Thanks, > Charles > > > gpiod_put(info->micd_pol_gpio); > > err_register: > > pm_runtime_disable(>dev); > > -- > > 2.17.1 > >
Re: [PATCH v6] checkpatch: add support to check 'Fixes:' tag format
On Mon, May 04, 2020 at 11:34:31AM -0700, Joe Perches wrote:
> On Mon, 2020-05-04 at 16:20 +0800, Wang YanQing wrote:
> > According to submitting-patches.rst, 'Fixes:' tag has a little
> > stricter condition about the one line summary than normal git
> > commit description:
> > “...
> > Do not split the tag across multiple lines, tags are exempt from
> > the "wrap at 75 columns" rule in order to simplify parsing scripts
> > ...”
> >
> > And there is no sanity check for 'Fixes:' tag format in checkpatch
> > the same as GIT_COMMIT_ID for git commit description, so let's expand
> > the GIT_COMMIT_ID to add 'Fixes:' tag format check support.
> >
> > The check supports below formats:
> > Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number
> > of pages it actually freed")
> > Fixes: 85f7cd3a2aad ("Revert "media: Kconfig: better support hybrid TV
> > devices"")
> > Fixes: 878520ac45f9 ("ext4: save the error code which triggered...")
> > Fixes: 878520ac45f9 ("ext4: save the error code which triggered")
> > Fixes: 277f27e2f277 ("SUNRPC/cache: Allow garbage collection ... ")
> >
> > The check doesn't support below formats and it will emit diagnostics info
> > for them:
> > Fixes: f2c2e717642c ("usb: gadget: add raw-gadget interface"
> > Fixes: 6c73698904aa pinctrl: qcom: Introduce readl/writel accessors
> > Fixes: 3fd6e7d9a146 (ASoC: tas571x: New driver for TI TAS571x power
> > amplifiers)
> > Fixes: 55697cbb44e4 ("arm64: dts: renesas: r8a779{65,80,90}: Add IPMMU
> > devices nodes)
> > Fixes: ba35f8588f47 (“ipvlan: Defer multicast / broadcast processing to a
> > work-queue”)
> > Fixes: cd758a9b57ee "KVM: PPC: Book3S HV: Use __gfn_to_pfn_memslot in HPT
> > page fault handler"
> > Fixes: 9b1640686470 ("scsi: lpfc: Fix use-after-free mailbox cmd
> > completion")
> > Fixes: 03f6fc6de919 ('ASoC: rt5682: Add the soundwire support')
> > Fixes: 03404e8ae652("IB/mlx5: Add support to dropless RQ")
> >
> > Because after GIT_COMMIT_ID supports 'Fixes:' tag format check, it could do
> > the same check as the UNKNOWN_COMMIT_ID, so we don't need UNKNOWN_COMMIT_ID
> > anymore and I decide to delete it.
> >
> > Note: this patch also fixes double quotation mark issue for normal git
> > commit description, and now it supports double quotation mark in
> > title line, for example:
> > Commit e33e2241e272 ("Revert "cfg80211: Use 5MHz bandwidth by default
> > when checking usable channels"")
> >
> > Note: this patch also adds diagnostics info support for normal git commit
> > description format check.
>
> Thanks YanQing.
>
> All of this seems fine, but perhaps checkpatch's output message content
> could be a bit shorter. I'll give it a think for a while.
>
Hi! Joe
What are the status of these patches?
"[PATCH v2] checkpatch: fix can't check for too long invalid commit id"
"[PATCH v6] checkpatch: add support to check 'Fixes:' tag format"
"[PATCH v2] checkpatch: allow commit description spans across three lines"
This is a ping message, maybe you have forgot them?
Thanks.
Re: [PATCH] MAINTAINERS: Update my maintainer entries to reorder email addresses
On Fri, 2020-05-22 at 20:19 -0600, Shuah Khan wrote: > get_maintainer.pl picks only the first email address found in the file. > Reorder my email addresses so it finds my linuxfoundation.org email. OK. btw: --noremove-duplicates is also an option. For instance: $ ./scripts/get_maintainer.pl -f Documentation/usb/usbip_protocol.rst Valentina Manea (maintainer:USB OVER IP DRIVER) Shuah Khan (maintainer:USB OVER IP DRIVER) Greg Kroah-Hartman (supporter:USB SUBSYSTEM) Jonathan Corbet (maintainer:DOCUMENTATION) linux-...@vger.kernel.org (open list:USB OVER IP DRIVER) linux-...@vger.kernel.org (open list:DOCUMENTATION) linux-kernel@vger.kernel.org (open list) vs: $ ./scripts/get_maintainer.pl --noremove-duplicates -f Documentation/usb/usbip_protocol.rst Valentina Manea (maintainer:USB OVER IP DRIVER) Shuah Khan (maintainer:USB OVER IP DRIVER) Shuah Khan (maintainer:USB OVER IP DRIVER) Greg Kroah-Hartman (supporter:USB SUBSYSTEM) Jonathan Corbet (maintainer:DOCUMENTATION) linux-...@vger.kernel.org (open list:USB OVER IP DRIVER) linux-...@vger.kernel.org (open list:DOCUMENTATION) linux-kernel@vger.kernel.org (open list)
Re: umip: AMD Ryzen 3900X, pagefault after emulate SLDT/SIDT instruction
On 11:56 19.05.20, Brendan Shanks wrote: > The problem is that the kernel does not emulate/spoof the SLDT instruction, > only SGDT, SIDT, and SMSW. > SLDT and STR weren't thought to be commonly used, so emulation/spoofing > wasn’t added. > In the last few months I have seen reports of one or two (32-bit) Windows > games that use SLDT though. > Can you share more information about the application you’re running? This is basically the "minimal" reproducer for the issue I've been observed (as by the previously linked article): https://gist.githubusercontent.com/andir/071981717460242a1df2e0fc20836fdc/raw/0c31877aa7ee59146596fe68934f9cecb5c998ae/test.c
[PATCH] MAINTAINERS: Update my maintainer entries to reorder email addresses
get_maintainer.pl picks only the first email address found in the file. Reorder my email addresses so it finds my linuxfoundation.org email. Signed-off-by: Shuah Khan --- MAINTAINERS | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index ecc0749810b0..dbad8b18bfe6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4404,8 +4404,8 @@ F:include/linux/cpuidle.h CPU POWER MONITORING SUBSYSTEM M: Thomas Renninger -M: Shuah Khan M: Shuah Khan +M: Shuah Khan L: linux...@vger.kernel.org S: Maintained F: tools/power/cpupower/ @@ -9238,8 +9238,8 @@ F:include/uapi/linux/sunrpc/ F: net/sunrpc/ KERNEL SELFTEST FRAMEWORK -M: Shuah Khan M: Shuah Khan +M: Shuah Khan L: linux-kselft...@vger.kernel.org S: Maintained Q: https://patchwork.kernel.org/project/linux-kselftest/list/ @@ -17484,8 +17484,8 @@ F: drivers/usb/common/usb-otg-fsm.c USB OVER IP DRIVER M: Valentina Manea -M: Shuah Khan M: Shuah Khan +M: Shuah Khan L: linux-...@vger.kernel.org S: Maintained F: Documentation/usb/usbip_protocol.rst -- 2.25.1
Re: umip: AMD Ryzen 3900X, pagefault after emulate SLDT/SIDT instruction
On 12:43 19.05.20, Ricardo Neri wrote: > I have a patch for this already that I wrote for testing purposes: > https://github.com/ricardon/tip/commit/1692889cb3f8accb523d44b682458e234b93be50 > Perhaps it can be used as a starting point? Not sure what the spoofing > value should be, though. Perhaps 0? I tried the above patch (in modified/rebased version; hope that didn't kill it [0]). The results are negative, as without the patch. [0] https://github.com/andir/linux/commit/bda858f44a860762bc484da62833f57462220874
Re: [PATCH] iio: light: iqs621: remove usage of iio_priv_to_dev()
Hi Alexandru,
On Fri, May 22, 2020 at 09:54:42AM +0300, Alexandru Ardelean wrote:
> We may want to get rid of the iio_priv_to_dev() helper. That's a bit
> uncertain at this point. The reason is that we will hide some of the
> members of the iio_dev structure (to prevent drivers from accessing them
> directly), and that will also mean hiding the implementation of the
> iio_priv_to_dev() helper inside the IIO core.
>
> Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
> may not be fast anymore, so a general idea is to try to get rid of the
> iio_priv_to_dev() altogether.
>
> For this driver, removing iio_priv_to_dev() means keeping a reference
> on the state struct.
>
> Signed-off-by: Alexandru Ardelean
> ---
> drivers/iio/light/iqs621-als.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
As with the iqs624 patch:
Acked-by: Jeff LaBundy
>
> diff --git a/drivers/iio/light/iqs621-als.c b/drivers/iio/light/iqs621-als.c
> index b2988a782bd0..1a056e2446ab 100644
> --- a/drivers/iio/light/iqs621-als.c
> +++ b/drivers/iio/light/iqs621-als.c
> @@ -36,6 +36,7 @@
>
> struct iqs621_als_private {
> struct iqs62x_core *iqs62x;
> + struct iio_dev *indio_dev;
> struct notifier_block notifier;
> struct mutex lock;
> bool light_en;
> @@ -103,7 +104,7 @@ static int iqs621_als_notifier(struct notifier_block
> *notifier,
>
> iqs621_als = container_of(notifier, struct iqs621_als_private,
> notifier);
> - indio_dev = iio_priv_to_dev(iqs621_als);
> + indio_dev = iqs621_als->indio_dev;
> timestamp = iio_get_time_ns(indio_dev);
>
> mutex_lock(_als->lock);
> @@ -191,7 +192,7 @@ static int iqs621_als_notifier(struct notifier_block
> *notifier,
> static void iqs621_als_notifier_unregister(void *context)
> {
> struct iqs621_als_private *iqs621_als = context;
> - struct iio_dev *indio_dev = iio_priv_to_dev(iqs621_als);
> + struct iio_dev *indio_dev = iqs621_als->indio_dev;
> int ret;
>
> ret = blocking_notifier_chain_unregister(_als->iqs62x->nh,
> @@ -551,6 +552,7 @@ static int iqs621_als_probe(struct platform_device *pdev)
>
> iqs621_als = iio_priv(indio_dev);
> iqs621_als->iqs62x = iqs62x;
> + iqs621_als->indio_dev = indio_dev;
>
> if (iqs62x->dev_desc->prod_num == IQS622_PROD_NUM) {
> ret = regmap_read(iqs62x->regmap, IQS622_IR_THRESH_TOUCH,
> --
> 2.25.1
>
Kind regards,
Jeff LaBundy
Re: [PATCH] iio: position: iqs624: remove usage of iio_priv_to_dev()
Hi Alexandru,
On Fri, May 22, 2020 at 09:53:22AM +0300, Alexandru Ardelean wrote:
> We may want to get rid of the iio_priv_to_dev() helper. That's a bit
> uncertain at this point. The reason is that we will hide some of the
> members of the iio_dev structure (to prevent drivers from accessing them
> directly), and that will also mean hiding the implementation of the
> iio_priv_to_dev() helper inside the IIO core.
>
> Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
> may not be fast anymore, so a general idea is to try to get rid of the
> iio_priv_to_dev() altogether.
>
> For this driver, removing iio_priv_to_dev() also means keeping a reference
> on the state struct.
>
> Signed-off-by: Alexandru Ardelean
> ---
> drivers/iio/position/iqs624-pos.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
As a customer of iio, I find it handy that there is an "inverse" to iio_priv.
In this particular case it saves the container iio_dev from storing a pointer
to itself.
That being said, this patch is perfectly fine and I have no objection if this
is the route you and Jonathan opt to take. And so:
Acked-by: Jeff LaBundy
>
> diff --git a/drivers/iio/position/iqs624-pos.c
> b/drivers/iio/position/iqs624-pos.c
> index 77096c31c2ba..520dafbdc48f 100644
> --- a/drivers/iio/position/iqs624-pos.c
> +++ b/drivers/iio/position/iqs624-pos.c
> @@ -23,6 +23,7 @@
>
> struct iqs624_pos_private {
> struct iqs62x_core *iqs62x;
> + struct iio_dev *indio_dev;
> struct notifier_block notifier;
> struct mutex lock;
> bool angle_en;
> @@ -59,7 +60,7 @@ static int iqs624_pos_notifier(struct notifier_block
> *notifier,
>
> iqs624_pos = container_of(notifier, struct iqs624_pos_private,
> notifier);
> - indio_dev = iio_priv_to_dev(iqs624_pos);
> + indio_dev = iqs624_pos->indio_dev;
> timestamp = iio_get_time_ns(indio_dev);
>
> iqs62x = iqs624_pos->iqs62x;
> @@ -98,7 +99,7 @@ static int iqs624_pos_notifier(struct notifier_block
> *notifier,
> static void iqs624_pos_notifier_unregister(void *context)
> {
> struct iqs624_pos_private *iqs624_pos = context;
> - struct iio_dev *indio_dev = iio_priv_to_dev(iqs624_pos);
> + struct iio_dev *indio_dev = iqs624_pos->indio_dev;
> int ret;
>
> ret = blocking_notifier_chain_unregister(_pos->iqs62x->nh,
> @@ -243,6 +244,7 @@ static int iqs624_pos_probe(struct platform_device *pdev)
>
> iqs624_pos = iio_priv(indio_dev);
> iqs624_pos->iqs62x = iqs62x;
> + iqs624_pos->indio_dev = indio_dev;
>
> indio_dev->modes = INDIO_DIRECT_MODE;
> indio_dev->dev.parent = >dev;
> --
> 2.25.1
>
Kind regards,
Jeff LaBundy
Re: [PATCH v2] fpga: dfl: afu: convert get_user_pages() --> pin_user_pages()
On 2020-05-19 13:14, John Hubbard wrote:
This code was using get_user_pages_fast(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages_fast() + put_page() calls to
pin_user_pages_fast() + unpin_user_pages() calls.
There is some helpful background in [2]: basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
Cc: Xu Yilun
Cc: Wu Hao
Cc: Moritz Fischer
Cc: linux-f...@vger.kernel.org
Signed-off-by: John Hubbard
Hi Moritz and FPGA developers,
Is this OK? And if so, is it going into your git tree? Or should I
send it up through a different tree? (I'm new to the FPGA development
model).
thanks,
--
John Hubbard
NVIDIA
---
Hi,
Changes since v1:
Changed the label from "put_pages", to "unpin_pages".
thanks,
John Hubbard
NVIDIA
drivers/fpga/dfl-afu-dma-region.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/fpga/dfl-afu-dma-region.c
b/drivers/fpga/dfl-afu-dma-region.c
index 62f924489db5..a31dd3a7e581 100644
--- a/drivers/fpga/dfl-afu-dma-region.c
+++ b/drivers/fpga/dfl-afu-dma-region.c
@@ -16,15 +16,6 @@
#include "dfl-afu.h"
-static void put_all_pages(struct page **pages, int npages)
-{
- int i;
-
- for (i = 0; i < npages; i++)
- if (pages[i])
- put_page(pages[i]);
-}
-
void afu_dma_region_init(struct dfl_feature_platform_data *pdata)
{
struct dfl_afu *afu = dfl_fpga_pdata_get_private(pdata);
@@ -57,11 +48,11 @@ static int afu_dma_pin_pages(struct
dfl_feature_platform_data *pdata,
goto unlock_vm;
}
- pinned = get_user_pages_fast(region->user_addr, npages, FOLL_WRITE,
+ pinned = pin_user_pages_fast(region->user_addr, npages, FOLL_WRITE,
region->pages);
if (pinned < 0) {
ret = pinned;
- goto put_pages;
+ goto unpin_pages;
} else if (pinned != npages) {
ret = -EFAULT;
goto free_pages;
@@ -71,8 +62,8 @@ static int afu_dma_pin_pages(struct dfl_feature_platform_data
*pdata,
return 0;
-put_pages:
- put_all_pages(region->pages, pinned);
+unpin_pages:
+ unpin_user_pages(region->pages, pinned);
free_pages:
kfree(region->pages);
unlock_vm:
@@ -94,7 +85,7 @@ static void afu_dma_unpin_pages(struct
dfl_feature_platform_data *pdata,
long npages = region->length >> PAGE_SHIFT;
struct device *dev = >dev->dev;
- put_all_pages(region->pages, npages);
+ unpin_user_pages(region->pages, npages);
kfree(region->pages);
account_locked_vm(current->mm, npages, false);
[PATCH 05/11] fs: add FMODE_BUF_RASYNC
If set, this indicates that the file system supports IOCB_WAITQ for buffered reads. Signed-off-by: Jens Axboe --- include/linux/fs.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/fs.h b/include/linux/fs.h index 82b989695ab9..0ef5f5973b1c 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -175,6 +175,9 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset, /* File does not contribute to nr_files count */ #define FMODE_NOACCOUNT((__force fmode_t)0x2000) +/* File supports async buffered reads */ +#define FMODE_BUF_RASYNC ((__force fmode_t)0x4000) + /* * Flag for rw_copy_check_uvector and compat_rw_copy_check_uvector * that indicates that they should check the contents of the iovec are -- 2.26.2
[PATCH 03/11] mm: add support for async page locking
Normally waiting for a page to become unlocked, or locking the page,
requires waiting for IO to complete. Add support for lock_page_async()
and wait_on_page_locked_async(), which are callback based instead. This
allows a caller to get notified when a page becomes unlocked, rather
than wait for it.
We use the iocb->private field to pass in this necessary data for this
to happen. struct wait_page_key is made public, and we define struct
wait_page_async as the interface between the caller and the core.
Signed-off-by: Jens Axboe
---
include/linux/fs.h | 2 ++
include/linux/pagemap.h | 21
mm/filemap.c| 56 +++--
3 files changed, 72 insertions(+), 7 deletions(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 7e84d823c6a8..82b989695ab9 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -314,6 +314,8 @@ enum rw_hint {
#define IOCB_SYNC (1 << 5)
#define IOCB_WRITE (1 << 6)
#define IOCB_NOWAIT(1 << 7)
+/* iocb->private holds wait_page_async struct */
+#define IOCB_WAITQ (1 << 8)
struct kiocb {
struct file *ki_filp;
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index a8f7bd8ea1c6..e260bcd071e4 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -456,8 +456,21 @@ static inline pgoff_t linear_page_index(struct
vm_area_struct *vma,
return pgoff;
}
+/* This has the same layout as wait_bit_key - see fs/cachefiles/rdwr.c */
+struct wait_page_key {
+ struct page *page;
+ int bit_nr;
+ int page_match;
+};
+
+struct wait_page_async {
+ struct wait_queue_entry wait;
+ struct wait_page_key key;
+};
+
extern void __lock_page(struct page *page);
extern int __lock_page_killable(struct page *page);
+extern int __lock_page_async(struct page *page, struct wait_page_async *wait);
extern int __lock_page_or_retry(struct page *page, struct mm_struct *mm,
unsigned int flags);
extern void unlock_page(struct page *page);
@@ -494,6 +507,14 @@ static inline int lock_page_killable(struct page *page)
return 0;
}
+static inline int lock_page_async(struct page *page,
+ struct wait_page_async *wait)
+{
+ if (!trylock_page(page))
+ return __lock_page_async(page, wait);
+ return 0;
+}
+
/*
* lock_page_or_retry - Lock the page, unless this would block and the
* caller indicated that it can handle a retry.
diff --git a/mm/filemap.c b/mm/filemap.c
index 80747f1377d5..a01daafd49fd 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -990,13 +990,6 @@ void __init pagecache_init(void)
page_writeback_init();
}
-/* This has the same layout as wait_bit_key - see fs/cachefiles/rdwr.c */
-struct wait_page_key {
- struct page *page;
- int bit_nr;
- int page_match;
-};
-
struct wait_page_queue {
struct page *page;
int bit_nr;
@@ -1210,6 +1203,50 @@ int wait_on_page_bit_killable(struct page *page, int
bit_nr)
}
EXPORT_SYMBOL(wait_on_page_bit_killable);
+static int __wait_on_page_locked_async(struct page *page,
+ struct wait_page_async *wait, bool set)
+{
+ struct wait_queue_head *q = page_waitqueue(page);
+ int ret = 0;
+
+ wait->key.page = page;
+ wait->key.bit_nr = PG_locked;
+
+ spin_lock_irq(>lock);
+ if (set)
+ ret = !trylock_page(page);
+ else
+ ret = PageLocked(page);
+ if (ret) {
+ __add_wait_queue_entry_tail(q, >wait);
+ SetPageWaiters(page);
+ if (set)
+ ret = !trylock_page(page);
+ else
+ ret = PageLocked(page);
+ /*
+* If we were succesful now, we know we're still on the
+* waitqueue as we're still under the lock. This means it's
+* safe to remove and return success, we know the callback
+* isn't going to trigger.
+*/
+ if (!ret)
+ __remove_wait_queue(q, >wait);
+ else
+ ret = -EIOCBQUEUED;
+ }
+ spin_unlock_irq(>lock);
+ return ret;
+}
+
+static int wait_on_page_locked_async(struct page *page,
+struct wait_page_async *wait)
+{
+ if (!PageLocked(page))
+ return 0;
+ return __wait_on_page_locked_async(compound_head(page), wait, false);
+}
+
/**
* put_and_wait_on_page_locked - Drop a reference and wait for it to be
unlocked
* @page: The page to wait for.
@@ -1372,6 +1409,11 @@ int __lock_page_killable(struct page *__page)
}
EXPORT_SYMBOL_GPL(__lock_page_killable);
+int __lock_page_async(struct page *page, struct wait_page_async *wait)
+{
+ return __wait_on_page_locked_async(page, wait,
[PATCH 01/11] block: read-ahead submission should imply no-wait as well
As read-ahead is opportunistic, don't block for request allocation.
Signed-off-by: Jens Axboe
---
include/linux/blk_types.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
index ccb895f911b1..c296463c15eb 100644
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -374,7 +374,8 @@ enum req_flag_bits {
#define REQ_INTEGRITY (1ULL << __REQ_INTEGRITY)
#define REQ_FUA(1ULL << __REQ_FUA)
#define REQ_PREFLUSH (1ULL << __REQ_PREFLUSH)
-#define REQ_RAHEAD (1ULL << __REQ_RAHEAD)
+#define REQ_RAHEAD \
+ ((1ULL << __REQ_RAHEAD) | (1ULL << __REQ_NOWAIT))
#define REQ_BACKGROUND (1ULL << __REQ_BACKGROUND)
#define REQ_NOWAIT (1ULL << __REQ_NOWAIT)
#define REQ_CGROUP_PUNT(1ULL << __REQ_CGROUP_PUNT)
--
2.26.2
[PATCH 07/11] block: flag block devices as supporting IOCB_WAITQ
Signed-off-by: Jens Axboe --- fs/block_dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/block_dev.c b/fs/block_dev.c index 86e2a7134513..ec8dccc81b65 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -1851,7 +1851,7 @@ static int blkdev_open(struct inode * inode, struct file * filp) */ filp->f_flags |= O_LARGEFILE; - filp->f_mode |= FMODE_NOWAIT; + filp->f_mode |= FMODE_NOWAIT | FMODE_BUF_RASYNC; if (filp->f_flags & O_NDELAY) filp->f_mode |= FMODE_NDELAY; -- 2.26.2
[PATCH 10/11] mm: add kiocb_wait_page_async_init() helper
Checks if the file supports it, and initializes the values that we need.
Caller passes in 'data' pointer, if any, and the callback function to
be used.
Signed-off-by: Jens Axboe
---
include/linux/pagemap.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index e260bcd071e4..21ced353310a 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -468,6 +468,24 @@ struct wait_page_async {
struct wait_page_key key;
};
+static inline int kiocb_wait_page_async_init(struct kiocb *kiocb,
+struct wait_page_async *wait,
+wait_queue_func_t func,
+void *data)
+{
+ if (kiocb->ki_filp->f_mode & FMODE_BUF_RASYNC) {
+ wait->wait.func = func;
+ wait->wait.private = data;
+ wait->wait.flags = 0;
+ INIT_LIST_HEAD(>wait.entry);
+ kiocb->ki_flags |= IOCB_WAITQ;
+ kiocb->private = wait;
+ return 0;
+ }
+
+ return -EOPNOTSUPP;
+}
+
extern void __lock_page(struct page *page);
extern int __lock_page_killable(struct page *page);
extern int __lock_page_async(struct page *page, struct wait_page_async *wait);
--
2.26.2
[PATCH 11/11] io_uring: support true async buffered reads, if file provides it
If the file is flagged with FMODE_BUF_RASYNC, then we don't have to punt
the buffered read to an io-wq worker. Instead we can rely on page
unlocking callbacks to support retry based async IO. This is a lot more
efficient than doing async thread offload.
The retry is done similarly to how we handle poll based retry. From
the unlock callback, we simply queue the retry to a task_work based
handler.
Signed-off-by: Jens Axboe
---
fs/io_uring.c | 102 ++
1 file changed, 102 insertions(+)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index e95481c552ff..9eeae10db648 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -498,6 +498,8 @@ struct io_async_rw {
struct iovec*iov;
ssize_t nr_segs;
ssize_t size;
+ struct wait_page_async wait;
+ struct callback_headtask_work;
};
struct io_async_ctx {
@@ -2568,6 +2570,102 @@ static int io_read_prep(struct io_kiocb *req, const
struct io_uring_sqe *sqe,
return 0;
}
+static void io_async_buf_cancel(struct callback_head *cb)
+{
+ struct io_async_rw *rw;
+ struct io_ring_ctx *ctx;
+ struct io_kiocb *req;
+
+ rw = container_of(cb, struct io_async_rw, task_work);
+ req = rw->wait.wait.private;
+ ctx = req->ctx;
+
+ spin_lock_irq(>completion_lock);
+ io_cqring_fill_event(req, -ECANCELED);
+ io_commit_cqring(ctx);
+ spin_unlock_irq(>completion_lock);
+
+ io_cqring_ev_posted(ctx);
+ req_set_fail_links(req);
+ io_double_put_req(req);
+}
+
+static void io_async_buf_retry(struct callback_head *cb)
+{
+ struct io_async_rw *rw;
+ struct io_ring_ctx *ctx;
+ struct io_kiocb *req;
+
+ rw = container_of(cb, struct io_async_rw, task_work);
+ req = rw->wait.wait.private;
+ ctx = req->ctx;
+
+ __set_current_state(TASK_RUNNING);
+ mutex_lock(>uring_lock);
+ __io_queue_sqe(req, NULL);
+ mutex_unlock(>uring_lock);
+}
+
+static int io_async_buf_func(struct wait_queue_entry *wait, unsigned mode,
+int sync, void *arg)
+{
+ struct wait_page_async *wp;
+ struct io_kiocb *req = wait->private;
+ struct io_async_rw *rw = >io->rw;
+ struct wait_page_key *key = arg;
+ struct task_struct *tsk;
+ int ret;
+
+ wp = container_of(wait, struct wait_page_async, wait);
+ if (wp->key.page != key->page)
+ return 0;
+ key->page_match = 1;
+ if (wp->key.bit_nr != key->bit_nr)
+ return 0;
+ if (test_bit(PG_locked, >page->flags))
+ return -1;
+
+ list_del_init(>entry);
+
+ init_task_work(>task_work, io_async_buf_retry);
+ /* submit ref gets dropped, acquire a new one */
+ refcount_inc(>refs);
+ tsk = req->task;
+ ret = task_work_add(tsk, >task_work, true);
+ if (unlikely(ret)) {
+ /* queue just for cancelation */
+ init_task_work(>task_work, io_async_buf_cancel);
+ tsk = io_wq_get_task(req->ctx->io_wq);
+ task_work_add(tsk, >task_work, true);
+ }
+ wake_up_process(tsk);
+ return 1;
+}
+
+static bool io_rw_should_retry(struct io_kiocb *req)
+{
+ struct kiocb *kiocb = >rw.kiocb;
+ int ret;
+
+ /* already tried, or we're doing O_DIRECT */
+ if (kiocb->ki_flags & (IOCB_DIRECT | IOCB_WAITQ))
+ return false;
+ /*
+* just use poll if we can, and don't attempt if the fs doesn't
+* support callback based unlocks
+*/
+ if (file_can_poll(req->file) || !(req->file->f_mode & FMODE_BUF_RASYNC))
+ return false;
+
+ ret = kiocb_wait_page_async_init(kiocb, >io->rw.wait,
+ io_async_buf_func, req);
+ if (ret)
+ return false;
+ get_task_struct(current);
+ req->task = current;
+ return true;
+}
+
static int io_read(struct io_kiocb *req, bool force_nonblock)
{
struct iovec inline_vecs[UIO_FASTIOV], *iovec = inline_vecs;
@@ -2601,6 +2699,7 @@ static int io_read(struct io_kiocb *req, bool
force_nonblock)
if (!ret) {
ssize_t ret2;
+retry:
if (req->file->f_op->read_iter)
ret2 = call_read_iter(req->file, kiocb, );
else
@@ -2619,6 +2718,9 @@ static int io_read(struct io_kiocb *req, bool
force_nonblock)
if (!(req->flags & REQ_F_NOWAIT) &&
!file_can_poll(req->file))
req->flags |= REQ_F_MUST_PUNT;
+ if (io_rw_should_retry(req))
+ goto retry;
+ kiocb->ki_flags &= ~IOCB_WAITQ;
return -EAGAIN;
}
}
--
2.26.2
Re: [PATCH] x86/mm/init: Stop printing pgt_buf addresses
On Sat, Feb 29, 2020 at 06:11:20PM -0500, Arvind Sankar wrote:
> This currently leaks kernel physical addresses into userspace.
>
> Signed-off-by: Arvind Sankar
> ---
> arch/x86/mm/init.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index e7bb483557c9..dc4711f09cdc 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -121,8 +121,6 @@ __ref void *alloc_low_pages(unsigned int num)
> } else {
> pfn = pgt_buf_end;
> pgt_buf_end += num;
> - printk(KERN_DEBUG "BRK [%#010lx, %#010lx] PGTABLE\n",
> - pfn << PAGE_SHIFT, (pgt_buf_end << PAGE_SHIFT) - 1);
> }
>
> for (i = 0; i < num; i++) {
> --
> 2.24.1
>
Ping.
https://lore.kernel.org/lkml/20200229231120.1147527-1-nived...@alum.mit.edu/
[PATCH 06/11] ext4: flag as supporting buffered async reads
Signed-off-by: Jens Axboe --- fs/ext4/file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ext4/file.c b/fs/ext4/file.c index 0d624250a62b..9f7d9bf427b4 100644 --- a/fs/ext4/file.c +++ b/fs/ext4/file.c @@ -826,7 +826,7 @@ static int ext4_file_open(struct inode * inode, struct file * filp) return ret; } - filp->f_mode |= FMODE_NOWAIT; + filp->f_mode |= FMODE_NOWAIT | FMODE_BUF_RASYNC; return dquot_file_open(inode, filp); } -- 2.26.2
[PATCH 04/11] mm: support async buffered reads in generic_file_buffered_read()
Use the async page locking infrastructure, if IOCB_WAITQ is set in the
passed in iocb. The caller must expect an -EIOCBQUEUED return value,
which means that IO is started but not done yet. This is similar to how
O_DIRECT signals the same operation. Once the callback is received by
the caller for IO completion, the caller must retry the operation.
Signed-off-by: Jens Axboe
---
mm/filemap.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index a01daafd49fd..b49836ff0fdc 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2086,17 +2086,25 @@ static ssize_t generic_file_buffered_read(struct kiocb
*iocb,
index, last_index - index);
}
if (!PageUptodate(page)) {
- if (iocb->ki_flags & IOCB_NOWAIT) {
- put_page(page);
- goto would_block;
- }
-
/*
* See comment in do_read_cache_page on why
* wait_on_page_locked is used to avoid unnecessarily
* serialisations and why it's safe.
*/
- error = wait_on_page_locked_killable(page);
+ if (iocb->ki_flags & IOCB_WAITQ) {
+ if (written) {
+ put_page(page);
+ goto out;
+ }
+ error = wait_on_page_locked_async(page,
+ iocb->private);
+ } else {
+ if (iocb->ki_flags & IOCB_NOWAIT) {
+ put_page(page);
+ goto would_block;
+ }
+ error = wait_on_page_locked_killable(page);
+ }
if (unlikely(error))
goto readpage_error;
if (PageUptodate(page))
@@ -2184,7 +2192,10 @@ static ssize_t generic_file_buffered_read(struct kiocb
*iocb,
page_not_up_to_date:
/* Get exclusive access to the page ... */
- error = lock_page_killable(page);
+ if (iocb->ki_flags & IOCB_WAITQ)
+ error = lock_page_async(page, iocb->private);
+ else
+ error = lock_page_killable(page);
if (unlikely(error))
goto readpage_error;
--
2.26.2
[PATCH 02/11] mm: allow read-ahead with IOCB_NOWAIT set
The read-ahead shouldn't block, so allow it to be done even if
IOCB_NOWAIT is set in the kiocb.
Signed-off-by: Jens Axboe
---
mm/filemap.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index 23a051a7ef0f..80747f1377d5 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2031,8 +2031,6 @@ static ssize_t generic_file_buffered_read(struct kiocb
*iocb,
page = find_get_page(mapping, index);
if (!page) {
- if (iocb->ki_flags & IOCB_NOWAIT)
- goto would_block;
page_cache_sync_readahead(mapping,
ra, filp,
index, last_index - index);
--
2.26.2
[PATCH 08/11] xfs: flag files as supporting buffered async reads
XFS uses generic_file_read_iter(), which already supports this. Signed-off-by: Jens Axboe --- fs/xfs/xfs_file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c index 4b8bdecc3863..97f44fbf17f2 100644 --- a/fs/xfs/xfs_file.c +++ b/fs/xfs/xfs_file.c @@ -1080,7 +1080,7 @@ xfs_file_open( return -EFBIG; if (XFS_FORCED_SHUTDOWN(XFS_M(inode->i_sb))) return -EIO; - file->f_mode |= FMODE_NOWAIT; + file->f_mode |= FMODE_NOWAIT | FMODE_BUF_RASYNC; return 0; } -- 2.26.2
[PATCH 09/11] btrfs: flag files as supporting buffered async reads
btrfs uses generic_file_read_iter(), which already supports this.
Signed-off-by: Jens Axboe
---
fs/btrfs/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index 719e68ab552c..c933b6a1b4a8 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -3480,7 +3480,7 @@ static loff_t btrfs_file_llseek(struct file *file, loff_t
offset, int whence)
static int btrfs_file_open(struct inode *inode, struct file *filp)
{
- filp->f_mode |= FMODE_NOWAIT;
+ filp->f_mode |= FMODE_NOWAIT | FMODE_BUF_RASYNC;
return generic_file_open(inode, filp);
}
--
2.26.2
[PATCHSET v2 RFC 0/11] Add support for async buffered reads
We technically support this already through io_uring, but it's implemented with a thread backend to support cases where we would block. This isn't ideal. After a few prep patches, the core of this patchset is adding support for async callbacks on page unlock. With this primitive, we can simply retry the IO operation. With io_uring, this works a lot like poll based retry for files that support it. If a page is currently locked and needed, -EIOCBQUEUED is returned with a callback armed. The callers callback is responsible for restarting the operation. With this callback primitive, we can add support for generic_file_buffered_read(), which is what most file systems end up using for buffered reads. XFS/ext4/btrfs/bdev is wired up, but probably trivial to add more. The file flags support for this by setting FMODE_BUF_RASYNC, similar to what we do for FMODE_NOWAIT. Open to suggestions here if this is the preferred method or not. In terms of results, I wrote a small test app that randomly reads 4G of data in 4K chunks from a file hosted by ext4. The app uses a queue depth of 32. preadv for comparison: real1m13.821s user0m0.558s sys 0m11.125s CPU ~13% Mainline: real0m12.054s user0m0.111s sys 0m5.659s CPU ~32% + ~50% == ~82% This patchset: real0m9.283s user0m0.147s sys 0m4.619s CPU ~52% The CPU numbers are just a rough estimate. For the mainline io_uring run, this includes the app itself and all the threads doing IO on its behalf (32% for the app, ~1.6% per worker and 32 of them). Context switch rate is much smaller with the patchset, since we only have the one task performing IO. The goal here is efficiency. Async thread offload adds latency, and it also adds noticable overhead on items such as adding pages to the page cache. By allowing proper async buffered read support, we don't have X threads hammering on the same inode page cache, we have just the single app actually doing IO. Series can also be found here: https://git.kernel.dk/cgit/linux-block/log/?h=async-buffered.2 or pull from: git://git.kernel.dk/linux-block async-buffered.2 fs/block_dev.c| 2 +- fs/btrfs/file.c | 2 +- fs/ext4/file.c| 2 +- fs/io_uring.c | 102 ++ fs/xfs/xfs_file.c | 2 +- include/linux/blk_types.h | 3 +- include/linux/fs.h| 5 ++ include/linux/pagemap.h | 39 +++ mm/filemap.c | 83 +-- 9 files changed, 219 insertions(+), 21 deletions(-) Changes since v1: - Fix an issue with inline page locking - Fix a potential race with __wait_on_page_locked_async() - Fix a hang related to not setting page_match, thus missing a wakeup -- Jens Axboe
Re: [PATCH 00/19] Implement NTB Controller using multiple PCI EP
Hi Rob,
On 5/22/2020 9:41 PM, Rob Herring wrote:
> On Thu, May 14, 2020 at 8:59 AM Kishon Vijay Abraham I wrote:
>>
>> This series is about implementing SW defined NTB using
>> multiple endpoint instances. This series has been tested using
>> 2 endpoint instances in J7 connected to two DRA7 boards. However there
>> is nothing platform specific for the NTB functionality.
>>
>> This was presented in Linux Plumbers Conference. The presentation
>> can be found @ [1]
>
> I'd like to know why putting this into DT is better than configfs.
> Does it solve some problem? Doing things in userspace is so much
> easier and more flexible than modifying and updating a DT.
It's a lot cleaner to have an endpoint function bound to two different endpoint
controller using device tree than configfs.
+epf_bus {
+ compatible = "pci-epf-bus";
+
+ func@0 {
+compatible = "pci-epf-ntb";
+epcs = <_ep>, <_ep>;
+epc-names = "primary", "secondary";
+reg = <0>;
+epf,vendor-id = /bits/ 16 <0x104c>;
+epf,device-id = /bits/ 16 <0xb00d>;
+num-mws = <4>;
+mws-size = <0x0 0x10>, <0x0 0x10>, <0x0 0x10>, <0x0
0x10>;
+ };
For device tree, just using phandles is enough and the driver can easily parse
DT to get EPCs bound to the endpoint function
+epcs = <_ep>, <_ep>;
+epc-names = "primary", "secondary";
This would be
ln -s functions/pci-epf-ntb/func1 controllers/290.pcie-ep/
ln -s functions/pci-epf-ntb/func1 controllers/291.pcie-ep/
pci_epc_epf_link() should then maintain the order of EPC bound to EPF and
designate one as PRIMARY_INTERFACE and the second as SECONDARY_INTERFACE.
pci_epf_bind() should be made to behave differently for NTB case.
While the standard properties (like vendorid, deviceid) has configfs entries,
additional logic would be required for adding function specific fields like
num-mws and mws-size above.
While all this support could be added in configfs, it looks simpler to
represent then in DT.
>
> I don't really think the PCI endpoint stuff is mature enough to be
> putting into DT either.
I think this will anyways come when we have to export real HW peripherals to
the remote HOST using EP controller.
Thanks
Kishon
[PATCH 1/1] vfio/spapr_tce: convert get_user_pages() --> pin_user_pages()
This code was using get_user_pages*(), in a "Case 2" scenario (DMA/RDMA), using the categorization from [1]. That means that it's time to convert the get_user_pages*() + put_page() calls to pin_user_pages*() + unpin_user_pages() calls. There is some helpful background in [2]: basically, this is a small part of fixing a long-standing disconnect between pinning pages, and file systems' use of those pages. [1] Documentation/core-api/pin_user_pages.rst [2] "Explicit pinning of user-space pages": https://lwn.net/Articles/807108/ Cc: Alex Williamson Cc: Cornelia Huck Cc: k...@vger.kernel.org Signed-off-by: John Hubbard --- Hi, I'm compile-tested this, but am not able to run-time test, so any testing help is much appreciated! thanks, John Hubbard NVIDIA drivers/vfio/vfio_iommu_spapr_tce.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c index 16b3adc508db..fe888b5dcc00 100644 --- a/drivers/vfio/vfio_iommu_spapr_tce.c +++ b/drivers/vfio/vfio_iommu_spapr_tce.c @@ -383,7 +383,7 @@ static void tce_iommu_unuse_page(struct tce_container *container, struct page *page; page = pfn_to_page(hpa >> PAGE_SHIFT); - put_page(page); + unpin_user_page(page); } static int tce_iommu_prereg_ua_to_hpa(struct tce_container *container, @@ -486,7 +486,7 @@ static int tce_iommu_use_page(unsigned long tce, unsigned long *hpa) struct page *page = NULL; enum dma_data_direction direction = iommu_tce_direction(tce); - if (get_user_pages_fast(tce & PAGE_MASK, 1, + if (pin_user_pages_fast(tce & PAGE_MASK, 1, direction != DMA_TO_DEVICE ? FOLL_WRITE : 0, ) != 1) return -EFAULT; -- 2.26.2
Re: [PATCH v4 3/8] spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4
On Sat, May 23, 2020 at 12:29 AM Mark Brown wrote:
>
> On Fri, May 22, 2020 at 11:59:25PM +0800, dillon min wrote:
>
> > but, after spi-core create a dummy tx_buf or rx_buf, then i can't get
> > the correct spi_3wire direction.
> > actually, this dummy tx_buf is useless for SPI_3WIRE. it's has meaning
> > for SPI_SIMPLE_RX mode,
> > simulate SPI_FULL_DUMPLEX
>
> Oh, that's annoying. I think the fix here is in the core, it should
> ignore MUST_TX and MUST_RX in 3WIRE mode since they clearly make no
> sense there.
How about add below changes to spi-core
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 8994545..bfd465c 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1022,7 +1022,8 @@ static int spi_map_msg(struct spi_controller
*ctlr, struct spi_message *msg)
void *tmp;
unsigned int max_tx, max_rx;
- if (ctlr->flags & (SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX)) {
+ if ((ctlr->flags & (SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX)) &&
+ !(msg->spi->mode & SPI_3WIRE)) {
max_tx = 0;
max_rx = 0;
for my board, lcd panel ilitek ill9341 use 3wire mode, gyro l3gd20 use
simplex rx mode.
it's has benefits to l3gd20, no impact to ili9341.
if it's fine to spi-core, i will include it to my next submits.
thanks
best regards.
Dillon
Re: [PATCH] mm/compaction: avoid VM_BUG_ON(PageSlab()) in page_mapcount()
On Wed, 13 May 2020 17:05:25 +0300 Konstantin Khlebnikov
wrote:
> Function isolate_migratepages_block() runs some checks out of lru_lock
> when choose pages for migration. After checking PageLRU() it checks extra
> page references by comparing page_count() and page_mapcount(). Between
> these two checks page could be removed from lru, freed and taken by slab.
>
> As a result this race triggers VM_BUG_ON(PageSlab()) in page_mapcount().
> Race window is tiny. For certain workload this happens around once a year.
>
>
> page:ea0105ca9380 count:1 mapcount:0 mapping:88ff7712c180 index:0x0
> compound_mapcount: 0
> flags: 0x5008100(slab|head)
> raw: 05008100 dead0100 dead0200 88ff7712c180
> raw: 80200020 0001
> page dumped because: VM_BUG_ON_PAGE(PageSlab(page))
> [ cut here ]
> kernel BUG at ./include/linux/mm.h:628!
> invalid opcode: [#1] SMP NOPTI
> CPU: 77 PID: 504 Comm: kcompactd1 Tainted: GW 4.19.109-27 #1
> Hardware name: Yandex T175-N41-Y3N/MY81-EX0-Y3N, BIOS R05 06/20/2019
> RIP: 0010:isolate_migratepages_block+0x986/0x9b0
>
>
> To fix just opencode page_mapcount() in racy check for 0-order case and
> recheck carefully under lru_lock when page cannot escape from lru.
>
> Also add checking extra references for file pages and swap cache.
I dunno, this code looks quite nasty. I'm more thinking we should
revert and rethink David's 119d6d59dcc0980dcd58 ("mm, compaction: avoid
isolating pinned pages").
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -935,12 +935,16 @@ isolate_migratepages_block(struct compact_control *cc,
> unsigned long low_pfn,
> }
>
> /*
> - * Migration will fail if an anonymous page is pinned in memory,
> + * Migration will fail if an page is pinned in memory,
>* so avoid taking lru_lock and isolating it unnecessarily in an
> - * admittedly racy check.
> + * admittedly racy check simplest case for 0-order pages.
> + *
> + * Open code page_mapcount() to avoid VM_BUG_ON(PageSlab(page)).
> + * Page could have extra reference from mapping or swap cache.
>*/
> - if (!page_mapping(page) &&
> - page_count(page) > page_mapcount(page))
> + if (!PageCompound(page) &&
> + page_count(page) > atomic_read(>_mapcount) + 1 +
> + (!PageAnon(page) || PageSwapCache(page)))
> goto isolate_fail;
OK, we happened to notice this because we happened to trigger a
!PageSlab assertion. But if this page has been freed and reused for
slab, it could have been reused for *anything*? Perhaps it was reused
as a migratable page which we'll go ahead and migrate even though we no
longer should. There are various whacky parts of the kernel which
(ab)use surprising struct page fields in surprising ways - how do we
know it isn't one of those which now happens to look like a migratable
page?
I also worry about the next test:
/*
* Only allow to migrate anonymous pages in GFP_NOFS context
* because those do not depend on fs locks.
*/
if (!(cc->gfp_mask & __GFP_FS) && page_mapping(page))
goto isolate_fail;
This page isn't PageLocked(), is it? It could be a recycled page which
is will be getting its ->mapping set one nanosecond hence.
> /*
> @@ -975,6 +979,11 @@ isolate_migratepages_block(struct compact_control *cc,
> unsigned long low_pfn,
> low_pfn += compound_nr(page) - 1;
> goto isolate_fail;
> }
> +
> + /* Recheck page extra references under lock */
> + if (page_count(page) > page_mapcount(page) +
> + (!PageAnon(page) || PageSwapCache(page)))
> + goto isolate_fail;
> }
>
> lruvec = mem_cgroup_page_lruvec(page, pgdat);
>
Re: [PATCH v3 07/19] mm: memcg/slab: allocate obj_cgroups for non-root slab pages
On Fri, May 22, 2020 at 08:27:15PM +0200, Vlastimil Babka wrote:
> On 4/22/20 10:46 PM, Roman Gushchin wrote:
> > Allocate and release memory to store obj_cgroup pointers for each
> > non-root slab page. Reuse page->mem_cgroup pointer to store a pointer
> > to the allocated space.
> >
> > To distinguish between obj_cgroups and memcg pointers in case
> > when it's not obvious which one is used (as in page_cgroup_ino()),
> > let's always set the lowest bit in the obj_cgroup case.
> >
> > Signed-off-by: Roman Gushchin
>
> Reviewed-by: Vlastimil Babka
Thank you!
>
> But I have a suggestion:
>
> ...
>
> > --- a/include/linux/slub_def.h
> > +++ b/include/linux/slub_def.h
> > @@ -191,4 +191,6 @@ static inline unsigned int obj_to_index(const struct
> > kmem_cache *cache,
> > cache->reciprocal_size);
> > }
> >
> > +extern int objs_per_slab(struct kmem_cache *cache);
> > +
> > #endif /* _LINUX_SLUB_DEF_H */
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index 7f87a0eeafec..63826e460b3f 100644
>
> ...
>
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -5992,4 +5992,9 @@ ssize_t slabinfo_write(struct file *file, const char
> > __user *buffer,
> > {
> > return -EIO;
> > }
> > +
> > +int objs_per_slab(struct kmem_cache *cache)
> > +{
> > + return oo_objects(cache->oo);
> > +}
> > #endif /* CONFIG_SLUB_DEBUG */
> >
>
> It's somewhat unfortunate to function call just for this. Although perhaps
> compiler can be smart enough as charge_slab_page() (that callse
> objs_per_slab())
> is inline and called from alloc_slab_page() which is also in mm/slub.c.
>
> But it might be also a bit wasteful in case SLUB doesn't manage to allocate
> its
> desired order, but smaller. The actual number of objects is then in
> page->objects.
>
> So ideally this should use something like objs_per_slab_page(cache, page)
> where
> SLAB supplies cache->num and SLUB page->objects, both implementations inline,
> and ignoring the other parameter?
Yeah, good point, makes total sense to me. I'll implement it in the next version
of the patchset.
Thank you!
Re: [PATCH v4 07/14] PCI: cadence: Add new *ops* for CPU addr fixup
Hi Rob, On 5/22/2020 10:15 PM, Rob Herring wrote: > On Thu, May 21, 2020 at 5:35 AM Kishon Vijay Abraham I wrote: >> >> Hi Rob, >> >> On 5/21/2020 3:04 AM, Rob Herring wrote: >>> On Wed, May 06, 2020 at 08:44:22PM +0530, Kishon Vijay Abraham I wrote: Cadence driver uses "mem" memory resource to obtain the offset of configuration space address region, memory space address region and message space address region. The obtained offset is used to program the Address Translation Unit (ATU). However certain platforms like TI's J721E SoC require the absolute address to be programmed in the ATU and not just the offset. >>> >>> Once again, Cadence host binding is broken (or at least the example is). >>> The 'mem' region shouldn't even exist. It is overlapping the config >>> space and 'ranges': >>> >>> reg = <0x0 0xfb00 0x0 0x0100>, >>> <0x0 0x4100 0x0 0x1000>, >>> <0x0 0x4000 0x0 0x0400>; >>> reg-names = "reg", "cfg", "mem"; >>> >>> ranges = <0x0200 0x0 0x4200 0x0 0x4200 0x0 >>> 0x100>, >>> <0x0100 0x0 0x4300 0x0 0x4300 0x0 >>> 0x001>; >>> >>> >>> 16M of registers looks a bit odd. I guess it doesn't matter >>> unless you have a 32-bit platform and care about your virtual >>> space. Probably should have been 3 regions for LM, RP, and AT looking >>> at the driver. >> >> The "mem" region in never ioremapped. However $patch removes requiring to add >> "mem" memory resource. > > I was referring to ioremapping 'reg' region. > >>> >>> Whatever outbound address translation you need should be based on >>> 'ranges'. >> >> You mean we don't need to add "new *ops* for CPU addr fixup"?. The issue is >> ranges provides CPU address and PCI address. The CPU will access whatever is >> populated in ranges to access the PCI bus. However while programming the ATU, >> we cannot use the CPU address provided in ranges directly (in some platforms) >> because the controller does not see the full address and only the lower >> 28bits. > > Okay, that is clearer as to what the difference is. I think this > should be 2 patches. One dropping 'mem' usage and using a mask and the > 2nd making the mask per platform. hmm okay. > > Really, the parent node of the PCI controller should probably have > 'ranges' and you could extract a mask from that. Looks like that is > what you had for DRA7... I'm not sure if ABI stability is important > for the Cadence platform. I'd assume that's just some IP eval system > and probably not? Right TI's J721E should be the first HW platform to use Cadence in mainline. > > Why do you need an ops here? All you need is a mask value. So how do we get platform specific mask? Use a different binding to specify the mask value? > >> This similar restriction was there with Designware (mostly an integration >> issue) and we used *ops* to fixup the address that has to be programmed in >> ATU. >> The Designware initially used a wrapper so that ranges property can be >> directly >> used [1]. However this approach was later removed in [2] >> >> [1] -> https://lore.kernel.org/patchwork/patch/468523/ >> [2] -> https://lkml.org/lkml/2015/10/16/232 > > So while you had the data for a mask in DT, the driver now hardcodes it? Yes, that's correct. Which approach should we use for Cadence? Thanks Kishon
[PATCH] media: v4l2-ctrls: Add encoder constant quality control
When V4L2_CID_MPEG_VIDEO_BITRATE_MODE value is
V4L2_MPEG_VIDEO_BITRATE_MODE_CQ, encoder will produce
constant quality output indicated by
V4L2_CID_MPEG_VIDEO_CONSTANT_QUALITY control value.
Encoder will choose appropriate quantization parameter
and bitrate to produce requested frame quality level.
Signed-off-by: Maheshwar Ajja
---
Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst | 10 ++
drivers/media/v4l2-core/v4l2-ctrls.c | 2 ++
include/uapi/linux/v4l2-controls.h| 2 ++
3 files changed, 14 insertions(+)
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index d0d506a..b9d3f7a 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -581,6 +581,8 @@ enum v4l2_mpeg_video_bitrate_mode -
- Variable bitrate
* - ``V4L2_MPEG_VIDEO_BITRATE_MODE_CBR``
- Constant bitrate
+* - ``V4L2_MPEG_VIDEO_BITRATE_MODE_CQ``
+ - Constant quality
@@ -592,6 +594,14 @@ enum v4l2_mpeg_video_bitrate_mode -
the average video bitrate. It is ignored if the video bitrate mode
is set to constant bitrate.
+``V4L2_CID_MPEG_VIDEO_CONSTANT_QUALITY (integer)``
+Constant quality level control. This control is applicable when
+``V4L2_CID_MPEG_VIDEO_BITRATE_MODE`` value is
+``V4L2_MPEG_VIDEO_BITRATE_MODE_CQ``. Valid range is 1 to 100
+where 1 indicates lowest quality and 100 indicates highest quality.
+Encoder will decide the appropriate quantization parameter and
+bitrate to produce requested frame quality.
+
``V4L2_CID_MPEG_VIDEO_TEMPORAL_DECIMATION (integer)``
For every captured frame, skip this many subsequent frames (default
0).
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 1c617b4..f94cc9d 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -199,6 +199,7 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
static const char * const mpeg_video_bitrate_mode[] = {
"Variable Bitrate",
"Constant Bitrate",
+ "Constant Quality",
NULL
};
static const char * const mpeg_stream_type[] = {
@@ -982,6 +983,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS: return "HEVC
Slice Parameters";
case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE: return "HEVC
Decode Mode";
case V4L2_CID_MPEG_VIDEO_HEVC_START_CODE: return "HEVC
Start Code";
+ case V4L2_CID_MPEG_VIDEO_CONSTANT_QUALITY: return
"Constant Quality";
/* CAMERA controls */
/* Keep the order of the 'case's the same as in v4l2-controls.h! */
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 0ba1005..ca916da 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -375,6 +375,7 @@ enum v4l2_mpeg_video_aspect {
enum v4l2_mpeg_video_bitrate_mode {
V4L2_MPEG_VIDEO_BITRATE_MODE_VBR = 0,
V4L2_MPEG_VIDEO_BITRATE_MODE_CBR = 1,
+ V4L2_MPEG_VIDEO_BITRATE_MODE_CQ = 2,
};
#define V4L2_CID_MPEG_VIDEO_BITRATE(V4L2_CID_MPEG_BASE+207)
#define V4L2_CID_MPEG_VIDEO_BITRATE_PEAK (V4L2_CID_MPEG_BASE+208)
@@ -742,6 +743,7 @@ enum v4l2_cid_mpeg_video_hevc_size_of_length_field {
#define V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_BR (V4L2_CID_MPEG_BASE +
642)
#define V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES (V4L2_CID_MPEG_BASE +
643)
#define V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR (V4L2_CID_MPEG_BASE +
644)
+#define V4L2_CID_MPEG_VIDEO_CONSTANT_QUALITY (V4L2_CID_MPEG_BASE +
645)
/* MPEG-class control IDs specific to the CX2341x driver as defined by V4L2 */
#define V4L2_CID_MPEG_CX2341X_BASE
(V4L2_CTRL_CLASS_MPEG | 0x1000)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: KASAN: slab-out-of-bounds Read in ath9k_hif_usb_rx_cb
syzbot has found a reproducer for the following crash on: HEAD commit:806d8acc USB: dummy-hcd: use configurable endpoint naming .. git tree: https://github.com/google/kasan.git usb-fuzzer console output: https://syzkaller.appspot.com/x/log.txt?x=113b269a10 kernel config: https://syzkaller.appspot.com/x/.config?x=d800e9bad158025f dashboard link: https://syzkaller.appspot.com/bug?extid=c15a0a825788b6ba2bc4 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1060eee210 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1022b6e210 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+c15a0a825788b6ba2...@syzkaller.appspotmail.com == BUG: KASAN: slab-out-of-bounds in ath9k_hif_usb_rx_stream drivers/net/wireless/ath/ath9k/hif_usb.c:580 [inline] BUG: KASAN: slab-out-of-bounds in ath9k_hif_usb_rx_cb+0xad3/0xf90 drivers/net/wireless/ath/ath9k/hif_usb.c:666 Read of size 4 at addr 8881c2f5c0dc by task kworker/0:8/398 CPU: 0 PID: 398 Comm: kworker/0:8 Not tainted 5.7.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events request_firmware_work_func Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xef/0x16e lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xd3/0x314 mm/kasan/report.c:382 __kasan_report.cold+0x37/0x92 mm/kasan/report.c:511 kasan_report+0x33/0x50 mm/kasan/common.c:625 ath9k_hif_usb_rx_stream drivers/net/wireless/ath/ath9k/hif_usb.c:580 [inline] ath9k_hif_usb_rx_cb+0xad3/0xf90 drivers/net/wireless/ath/ath9k/hif_usb.c:666 __usb_hcd_giveback_urb+0x1f2/0x470 drivers/usb/core/hcd.c:1648 usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1713 dummy_timer+0x125e/0x32b4 drivers/usb/gadget/udc/dummy_hcd.c:1966 call_timer_fn+0x1ac/0x700 kernel/time/timer.c:1405 expire_timers kernel/time/timer.c:1450 [inline] __run_timers kernel/time/timer.c:1774 [inline] __run_timers kernel/time/timer.c:1741 [inline] run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1787 __do_softirq+0x21e/0x9aa kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0x178/0x1a0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:546 [inline] smp_apic_timer_interrupt+0x141/0x540 arch/x86/kernel/apic/apic.c:1140 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829 RIP: 0010:_raw_spin_unlock_irq+0x27/0x30 kernel/locking/spinlock.c:200 Code: 44 00 00 55 48 8b 74 24 08 48 89 fd 48 8d 7f 18 e8 1e b4 90 fb 48 89 ef e8 b6 b0 91 fb e8 a1 54 af fb fb 65 ff 0d 51 ca 6b 7a <5d> c3 0f 1f 80 00 00 00 00 55 48 89 fd 48 83 c7 18 53 48 89 f3 48 RSP: 0018:8881cd6175e8 EFLAGS: 0282 ORIG_RAX: ff13 RAX: 0007 RBX: 8881c1d04a40 RCX: 11270ab2 RDX: RSI: RDI: 8881c1d052bc RBP: 8881db234900 R08: 0001 R09: fbfff126c8c8 R10: 8936463f R11: fbfff126c8c7 R12: 8881db234900 R13: 8881ce3ee300 R14: R15: 0001 finish_lock_switch kernel/sched/core.c:3106 [inline] finish_task_switch+0x11d/0x5d0 kernel/sched/core.c:3206 context_switch kernel/sched/core.c:3370 [inline] __schedule+0x89a/0x1d80 kernel/sched/core.c:4083 preempt_schedule_common+0x30/0x60 kernel/sched/core.c:4239 _cond_resched+0x18/0x20 kernel/sched/core.c:5624 start_flush_work kernel/workqueue.c:2980 [inline] __flush_work+0x117/0xa90 kernel/workqueue.c:3044 __cancel_work_timer+0x32c/0x460 kernel/workqueue.c:3132 rhashtable_free_and_destroy+0x29/0x8b0 lib/rhashtable.c:1130 ieee80211_free_hw+0xab/0x270 net/mac80211/main.c:1407 ath9k_htc_probe_device+0x1c2/0x1da0 drivers/net/wireless/ath/ath9k/htc_drv_init.c:972 ath9k_htc_hw_init+0x31/0x60 drivers/net/wireless/ath/ath9k/htc_hst.c:501 ath9k_hif_usb_firmware_cb+0x274/0x510 drivers/net/wireless/ath/ath9k/hif_usb.c:1187 request_firmware_work_func+0x126/0x242 drivers/base/firmware_loader/main.c:1005 process_one_work+0x965/0x1630 kernel/workqueue.c:2268 worker_thread+0x96/0xe20 kernel/workqueue.c:2414 kthread+0x326/0x430 kernel/kthread.c:268 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:351 Allocated by task 150: save_stack+0x1b/0x40 mm/kasan/common.c:49 set_track mm/kasan/common.c:57 [inline] __kasan_kmalloc mm/kasan/common.c:495 [inline] __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:468 slab_post_alloc_hook mm/slab.h:586 [inline] slab_alloc_node mm/slub.c:2797 [inline] slab_alloc mm/slub.c:2805 [inline] kmem_cache_alloc+0xd8/0x300 mm/slub.c:2810 getname_flags fs/namei.c:138 [inline] getname_flags+0xd2/0x5b0 fs/namei.c:128 do_sys_openat2+0x3fc/0x7d0 fs/open.c:1142 do_sys_open+0xc3/0x140 fs/open.c:1164 do_syscall_64+0xb6/0x5a0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 Freed by task
Urgent Reply,
Dear Friend, I'm Mr. Scott Donald a Successful business Man. dealing with Exportation, I got your email contact through search to let you know my Ugly Situation Am a dying Man here in California Los Angeles Hospital Bed in (USA), I Lost my Wife and my only Daughter for Corona virus and my Doctor said to me that i don't have enough time to live any more, i have a project that am about to handover to you. i have already instructed the Barclay Bank of London to transfer my fund sum of £3,7M GBP to you as to enable you give 50% to Charitable Home and take 50% and i have already given all i have here in America to Charitable home I also ask my Doctor to help me get to you in case you did not hear from me again, i want to you see on video very urgent here is my Doctor Whatsapp Number for urgent notice +13019692737 Hope To Hear From You. i want to see you on Video call very urgent please. i'm sending this email to you for the second times yet no response from you Regards Mr. Scott Donald
ptrace: seccomp: Return value when the call was already invalid
I'm seeing the following while porting a ptracer from x86_64 to arm64 (cc'ing arm64 folks, but in this case x86_64 is the odd one out, I think other archs would be consistent with arm64). Consider userspace code like the following: ``` int ret = syscall(-10, 0); assert(ret == -ENOSYS); ``` (Never mind the fact that this is something userspace shouldn't do, I saw this in our test suite that tests corner cases where the ptracer shouldn't affect behavior). Now, if we have a seccomp filter that simply does SECCOMP_RET_TRACE, and a ptracer that simply does PTRACE_CONT, then the assert will fire/fail on arm64, but not on x86_64. The reason this happens is that the return value gets set early on x86_64, but this is not possible on arm64, because doing so would clobber the first argument register that it shares. As a result, no return value is set and `ret` retains the value that the first syscall argument used to have. I can work around this of course, but I guess my question is whether this is expected/ok, or you would expect an active ptracer that does not touch the registers not to affect behavior. Interestingly, arm64 does do something different if the syscall is -1 rather than -10, where early in the ptrace stop it does. ``` /* set default errno for user-issued syscall(-1) */ if (scno == NO_SYSCALL) regs->regs[0] = -ENOSYS; ``` I'm not sure that's great either since the ptracer may want to inspect x0 and arm64 does not make orig_x0 available via ptrace. To me this indicates that maybe this was intended to apply to any syscall skipped here, not just -1 (the different comes from the fact that seccomp considers any negative syscall a skip/fail, but on syscall-entry stops arm64 only considers a literal -1 a skip). On the other hand if this is deemed expected, I'll go ahead and submit a man-page patch to at least document this architecture difference. Keno
Re: [PATCH] media: v4l2-ctrls: Add encoded frame quality controls
Hi Hans,
Thank you for the suggestion. I will update the patch accordingly.
Regards,
Maheshwar.
On 2020-05-18 23:45, Hans Verkuil wrote:
Hi Maheshwar,
On 18/05/2020 23:09, ma...@codeaurora.org wrote:
Hi,
Regarding below patch -
HEIF/HEIC image encoding uses HEVC/AVC encoders and client can set
image
quality level using
V4L2_CID_MPEG_VIDEO_FRAME_QUALITY control.
Reference BITRATE_MODE_CQ at
https://developer.android.com/reference/android/media/MediaCodecInfo.EncoderCapabilities#BITRATE_MODE_CQ
So what you are really introducing here is a new enum
v4l2_mpeg_video_bitrate_mode
mode: V4L2_MPEG_VIDEO_BITRATE_MODE_CQ.
Why not just add that new mode, then add
V4L2_CID_MPEG_VIDEO_CONSTANT_QUALITY
which is only used if the bitrate mode is MODE_CQ.
That builds nicely on top of the already existing
V4L2_CID_MPEG_VIDEO_BITRATE_MODE
control.
Regards,
Hans
Regards,
Maheshwar.
On 2020-05-18 14:07, Maheshwar Ajja wrote:
When frame quality control is enabled encoder will choose
the appropriate quantization parameter and bitrate to
produce the client requested frame quality level.
When frame quality control is disabled then frame quality
is decided based on appropriate controls (i.e.
V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE and/or
V4L2_CID_MPEG_VIDEO_BITRATE_MODE)
Signed-off-by: Maheshwar Ajja
---
.../userspace-api/media/v4l/ext-ctrls-codec.rst | 16
drivers/media/v4l2-core/v4l2-ctrls.c | 3 +++
include/uapi/linux/v4l2-controls.h | 2 ++
3 files changed, 21 insertions(+)
diff --git
a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index d0d506a..495b39b 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -1081,6 +1081,22 @@ enum v4l2_mpeg_video_h264_entropy_mode -
Macroblock level rate control enable. Applicable to the MPEG4
and
H264 encoders.
+``V4L2_CID_MPEG_VIDEO_FRAME_QUALITY_ENABLE (boolean)``
+Encoded frame quality control enable. If this control is enabled
then
+the quality level of the encoded frame is set with control
+``V4L2_CID_MPEG_VIDEO_CONSTANT_QUALITY``. If this control is
disabled
+then the quality level of encoded frame is adjusted with
appropriate
+controls (e.g. ``V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE`` or
+``V4L2_CID_MPEG_VIDEO_BITRATE_MODE``). Applicable to encoders.
+
+``V4L2_CID_MPEG_VIDEO_FRAME_QUALITY (integer)``
+Encoded frame quality control. If the control
+``V4L2_CID_MPEG_VIDEO_FRAME_QUALITY_ENABLE`` is enabled then the
+quality of encoded frame is set with this control. Valid range
is
1 to
+100 where 1 indicates lowest quality and 100 indicates highest
quality.
+Encoder will decide the appropriate quantization parameter and
bitrate
+to produce requested frame quality. Applicable to encoders.
+
``V4L2_CID_MPEG_VIDEO_MPEG4_QPEL (boolean)``
Quarter pixel motion estimation for MPEG4. Applicable to the
MPEG4
encoder.
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 1c617b4..1477198 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -982,6 +982,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS: return "HEVC
Slice
Parameters";
case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE: return "HEVC
Decode
Mode";
case V4L2_CID_MPEG_VIDEO_HEVC_START_CODE: return "HEVC Start
Code";
+ case V4L2_CID_MPEG_VIDEO_FRAME_QUALITY_ENABLE: return "Frame
Quality
Enable";
+ case V4L2_CID_MPEG_VIDEO_FRAME_QUALITY: return "Frame
Quality";
/* CAMERA controls */
/* Keep the order of the 'case's the same as in v4l2-controls.h! */
@@ -1178,6 +1180,7 @@ void v4l2_ctrl_fill(u32 id, const char **name,
enum v4l2_ctrl_type *type,
case V4L2_CID_FLASH_READY:
case V4L2_CID_MPEG_VIDEO_DECODER_MPEG4_DEBLOCK_FILTER:
case V4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE:
+ case V4L2_CID_MPEG_VIDEO_FRAME_QUALITY_ENABLE:
case V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE:
case V4L2_CID_MPEG_VIDEO_MB_RC_ENABLE:
case V4L2_CID_MPEG_VIDEO_H264_8X8_TRANSFORM:
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 0ba1005..d97a934 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -742,6 +742,8 @@ enum
v4l2_cid_mpeg_video_hevc_size_of_length_field
{
#define
V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_BR (V4L2_CID_MPEG_BASE
+ 642)
#define
V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES (V4L2_CID_MPEG_BASE
+ 643)
#define
V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR (V4L2_CID_MPEG_BASE
+ 644)
+#define V4L2_CID_MPEG_VIDEO_FRAME_QUALITY_ENABLE (V4L2_CID_MPEG_BASE
+
645)
+#define
Re: [PATCH V2 1/2] rbtree_latch: quit searching when reaching to maximum depth
On Sat, May 16, 2020 at 12:01 AM Lai Jiangshan wrote:
>
> lib/rbtree.c has ensured that there is not possible to
> inadvertently cause (temporary) loops in the tree structure
> as seen in program order of the modifier. But loop is still
> possible to be seen in searcher due to CPU's reordering.
>
> for example:
> modifiersearcher
>
> left rotate at parent
> parent->rb_right is node
> search to parent
> parent->rb_right is node
> +->see node->rb_left changed
> WRITE_ONCE(parent->rb_right, tmp);-+ | node->rb_left is parennt
> no smp_wmb(), some ARCHs can | |
> reorder these two writes | | loop long between
> WRITE_ONCE(node->rb_left, parent);-+-+ parent and node
>|
>+--->finally see
> parent->rb_right
>
> The long loop won't stop until the modifer's CPU flushes
> its writes. Too avoid it, we should limit the searching depth.
> There are no more than (1< And the max_depth of a tree is no more than 2*lg(node_count+1),
> which is no mare than 2*BITS_PER_LONG.
>
> So the searching should stop when diving down up to
> 2*BITS_PER_LONG depth.
>
> Cc: Peter Zijlstra
> Cc: Paul E. McKenney
> Cc: Oleg Nesterov
> Cc: Michel Lespinasse
> Cc: Andrea Arcangeli
> Cc: Rik van Riel
> Cc: Mathieu Desnoyers
> Signed-off-by: Lai Jiangshan
> ---
Hello
Could anyone have a review or an ack on the updated patch?
Compared v1:
Applied Mathieu's suggest to change the changelog
Avoid the depth check on x86, so the patch makes no functionality
change on x86
And which tree should the patches route to? It is memory ordering
related.
Thanks
Lai
> include/linux/rbtree_latch.h | 39
> 1 file changed, 39 insertions(+)
>
> diff --git a/include/linux/rbtree_latch.h b/include/linux/rbtree_latch.h
> index 7d012faa509a..638942f53c0a 100644
> --- a/include/linux/rbtree_latch.h
> +++ b/include/linux/rbtree_latch.h
> @@ -102,11 +102,47 @@ __lt_erase(struct latch_tree_node *ltn, struct
> latch_tree_root *ltr, int idx)
> rb_erase(>node[idx], >tree[idx]);
> }
>
> +/*
> + * Beware when rbtree is being searched in RCU read sites.
> + *
> + * lib/rbtree.c has ensured that there is not possible to
> + * inadvertently cause (temporary) loops in the tree structure
> + * as seen in program order of the modifier. But loop is still
> + * possible to be seen in searcher due to CPU's reordering.
> + *
> + * for example:
> + * modifier searcher
> + *
> + * left rotate at parent search to parent
> + * parent->rb_right is node parent->rb_right is node
> + * +->see node->rb_left changed
> + * WRITE_ONCE(parent->rb_right, tmp);-+ | node->rb_left is parennt
> + * no smp_wmb(), some ARCHs can | |
> + * reorder these two writes | | loop long between
> + * WRITE_ONCE(node->rb_left, parent);-+-+ parent and node
> + * |
> + * +--->finally see
> + *parent->rb_right
> + *
> + * The long loop won't stop until the searcher finally see the changes
> + * from the modifier. Too avoid it, we should limit the searching depth.
> + *
> + * Limited by the address space of the kernel, there are no more than
> + * (1< + * no more than 2*lg(node_count+1), which is no mare than 2*BITS_PER_LONG.
> + *
> + * So the searching should stop when diving down up to
> + * 2*BITS_PER_LONG depth.
> + *
> + * Note: the above problem is not subject to the TSO memory model, such as
> + * x86, which can dispense with the depth check.
> + */
> static __always_inline struct latch_tree_node *
> __lt_find(void *key, struct latch_tree_root *ltr, int idx,
> int (*comp)(void *key, struct latch_tree_node *node))
> {
> struct rb_node *node = rcu_dereference_raw(ltr->tree[idx].rb_node);
> + int depth = 2 * BITS_PER_LONG;
> struct latch_tree_node *ltn;
> int c;
>
> @@ -120,6 +156,9 @@ __lt_find(void *key, struct latch_tree_root *ltr, int idx,
> node = rcu_dereference_raw(node->rb_right);
> else
> return ltn;
> +
> + if (!IS_ENABLED(CONFIG_X86) && (--depth < 0))
> + break;
> }
>
> return NULL;
> --
> 2.20.1
>
Re: [PATCH net-next 1/5] net: hns3: add support for VF to query ring and vector mapping
On 2020/5/23 1:39, Jakub Kicinski wrote: On Fri, 22 May 2020 10:49:42 +0800 Huazhong Tan wrote: From: Guangbin Huang This patch adds support for VF to query the mapping of ring and vector. Signed-off-by: Guangbin Huang Signed-off-by: Huazhong Tan Hi, Jakub. Could you explain a little more what this is doing? This patch just adds a new type of mailbox for VF to the mapping of ring and vector through PF. not a complicated feature;). Also what's using this? In the series nothing is making this request. As mentioned in the cover, "this is needed by the hns3 DPDK VF PMD driver", current the VF driver of linux kernel does need this info. Should this also mention in this commit log? Thanks. .
[tip:sched/core 1/2] kernel/sched/core.c:223:1: warning: unused function 'rq_csd_init'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core
head: 2a0a24ebb499c9d499eea948d3fc108f936e36d4
commit: 90b5363acd4739769c3f38c1aff16171bd133e8c [1/2] sched: Clean up
scheduler_ipi()
config: mips-randconfig-r006-20200521 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
3393cc4cebf9969db94dc424b7a2b6195589c33b)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install mips cross compiling tool for clang build
# apt-get install binutils-mips-linux-gnu
git checkout 90b5363acd4739769c3f38c1aff16171bd133e8c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>, old ones prefixed by <<):
kernel/sched/core.c:4190:35: warning: no previous prototype for function
'schedule_user'
asmlinkage __visible void __sched schedule_user(void)
^
kernel/sched/core.c:4190:22: note: declare 'static' if the function is not
intended to be used outside of this translation unit
asmlinkage __visible void __sched schedule_user(void)
^
static
>> kernel/sched/core.c:223:1: warning: unused function 'rq_csd_init'
rq_csd_init(struct rq call_single_data_t smp_call_func_t func)
^
kernel/sched/core.c:3744:20: warning: unused function 'sched_tick_start'
static inline void sched_tick_start(int cpu) { }
^
kernel/sched/core.c:3745:20: warning: unused function 'sched_tick_stop'
static inline void sched_tick_stop(int cpu) { }
^
fatal error: error in backend: Nested variants found in inline asm string: '
.set push
.set noat
.set push
.set arch=r4000
.if ( 0x00 ) != -1)) 0x00 ) != -1)) : ($( static struct ftrace_branch_data
__attribute__((__aligned__(4))) __attribute__((__section__("_ftrace_branch")))
__if_trace = $( .func = __func__, .file = "arch/mips/include/asm/cmpxchg.h",
.line = 163, $); 0x00 ) != -1)) : $))) ) && ( 0 ); .set push; .set mips64r2;
.rept 1; sync 0x00; .endr; .set pop; .else; ; .endif
1: ll $0, $2 # __cmpxchg_asm
bne $0, ${3:z}, 2f
.set pop
move $$1, ${4:z}
.set arch=r4000
sc $$1, $1
beqz $$1, 1b
.set pop
2: .if ( 0x00 ) != -1)) 0x00 ) != -1)) : ($( static struct ftrace_branch_data
__attribute__((__aligned__(4))) __attribute__((__section__("_ftrace_branch")))
__if_trace = $( .func = __func__, .file = "arch/mips/include/asm/cmpxchg.h",
.line = 163, $); 0x00 ) != -1)) : $))) ) && ( 0 ); .set push; .set mips64r2;
.rept 1; sync 0x00; .endr; .set pop; .else; ; .endif
'
clang-11: error: clang frontend command failed with exit code 70 (use -v to see
invocation)
clang version 11.0.0 (git://gitmirror/llvm_project
3393cc4cebf9969db94dc424b7a2b6195589c33b)
Target: mipsel-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/cross/clang-3393cc4ceb/bin
clang-11: note: diagnostic msg:
Makefile arch include kernel null.dwo scripts source usr
vim +/rq_csd_init +223 kernel/sched/core.c
221
222 static inline void
> 223 rq_csd_init(struct rq *rq, call_single_data_t *csd, smp_call_func_t
> func)
224 {
225 csd->flags = 0;
226 csd->func = func;
227 csd->info = rq;
228 }
229
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: Re: [PATCH v12 00/18] Enable FSGSBASE instructions
Don, Don Porter writes: > On 5/19/20 12:48 PM, Jarkko Sakkinen wrote: >> On Tue, May 19, 2020 at 01:03:25AM +0200, Thomas Gleixner wrote: >>> >>> That justifies to write books which recommend to load a kernel module >>> which creates a full unpriviledged root hole. I bet none of these papers >>> ever mentioned that. > > I wanted to clarify that we never intended the Graphene kernel module > you mention for production use, as well as to comment in support of this > patch. let me clarify, that despite your intentions: - there is not a single word in any paper, slide deck, documentation etc. which mentions that loading this module and enabling FSGSBASE behind the kernels back is a fully unpriviledged root hole. - the module lacks a big fat warning emitted to dmesg, that this turns the host kernel into a complete security disaster. - the module fails to set the TAINT_CRAP flag when initialized. This shows a pretty obvious discrepancy between intention and action. > Setting the fs register in userspace is an essential feature for running > legacy code in SGX. We have been following LKML discussions on this > instruction for years, and hoping this feature would be supported by > Linux, so that we can retire this module. The way to get things done in the kernel is to actively work on the problem. Hoping that someone else will fix that for you is naive at best. Wilful ignorance might be a less polite but nevertheless accurate term. > To our knowledge, every SGX library OS has a similar module, waiting > for this or a similar patch to be merged into Linux. This indicates a > growing user base that needs this instruction. I'm failing to understand that a whole industry which is so confident about their ultimate solution to the security problem puts possible users and customers into the situation to decide between: 1) Secure host kernel (with known limitations) 2) SGX enclaves I would not mind if this would be a choice between fire and frying pan, but this is a choice between a well understood reality and a very dangerous illusion. > Nonetheless, Graphene is moving towards adoption in production systems, > and we are actively working to make the code base secure and robust. > This issue has been on our to-do list before a production release. It > would certainly make our lives easier to deprecate our module and just > use a robust, in-kernel implementation. Would make your life easier? Having proper in kernel FSGSBASE support is the only solution to that problem and this has been true since the whole SGX frenzy started. Intel failed to upstream FSGSBASE since 2015 (sic!). See https://lore.kernel.org/lkml/alpine.deb.2.21.1903261010380.1...@nanos.tec.linutronix.de/ for a detailed time line. And that mail is more than a year old. Since then there happened even more trainwrecks including the revert of already queued patches a few days before the 5.3 merge window opened. After that we saw yet more broken variants of that patch set including the fail to provide information which is required to re-merge that. Instead of providing that information the next version re-introduced the wreckage which was carefully sorted out during earlier review cycles up to the revert. So you (and everybody else who has interrest in SGX) just sat there, watched and hoped that this will solve itself magically. And with that "hope" argument you really want to make me believe that all of this was against your intentions? It's beyond hillarious that the renewed attempt to get FSGSBASE support merged does not come from the company which has the main interest to get this solved, i.e Intel. Based on your argumentation that all of this is uninteded, I assume that the pull request on github which removes this security hole from graphene: https://github.com/oscarlab/graphene/pull/1529 is perfectly fine, right? Quite the contrary, it's completely usesless and at the same time perfectly fitting into this picture: The changelog is SGX marketing compliant: Zero technical content. Not a single word about the real implications of that blantant violation of any principle of sane (security) engineering. Not that I'm surprised about this. That change originates from Intel and the poor sod who had to place the pull request - coincidentally a few days after this insanity became public - was not allowed to spell out the real reasons why this removal is necessary. Please read security relevant changelogs in the kernel git tree and then explain to me the utter void in this one. Looking at the advertising which all involved parties including the Confidential Computing Consortium are conducting, plus the fact that Intel has major investments in SGX supporting companies and projects, this is one of the worst marketing scams I've seen in decades. This all violates the fundamental engineering principle of "correctnes first" and I'm flabbergasted that academic research has
[GIT PULL] SCSI fixes for 5.7-rc6
Three minor fixes, two in drivers, one to fix a hang after reset with
iSCSI, and one to avoid a spurious log message; and the final core one
to correct a suspend/resume miscount with quiesced devices.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Bodo Stroesser (1):
scsi: target: Put lun_ref at end of tmr processing
Can Guo (1):
scsi: pm: Balance pm_only counter of request queue during system resume
Ewan D. Milne (1):
scsi: qla2xxx: Do not log message when reading port speed via sysfs
And the diffstat:
drivers/scsi/qla2xxx/qla_attr.c| 3 ---
drivers/scsi/scsi_pm.c | 10 --
drivers/target/target_core_transport.c | 1 +
3 files changed, 9 insertions(+), 5 deletions(-)
With full diff below.
James
---
diff --git a/drivers/scsi/qla2xxx/qla_attr.c b/drivers/scsi/qla2xxx/qla_attr.c
index 33255968f03a..2c9e5ac24692 100644
--- a/drivers/scsi/qla2xxx/qla_attr.c
+++ b/drivers/scsi/qla2xxx/qla_attr.c
@@ -1850,9 +1850,6 @@ qla2x00_port_speed_show(struct device *dev, struct
device_attribute *attr,
return -EINVAL;
}
- ql_log(ql_log_info, vha, 0x70d6,
- "port speed:%d\n", ha->link_data_rate);
-
return scnprintf(buf, PAGE_SIZE, "%s\n", spd[ha->link_data_rate]);
}
diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
index 3717eea37ecb..5f0ad8b32e3a 100644
--- a/drivers/scsi/scsi_pm.c
+++ b/drivers/scsi/scsi_pm.c
@@ -80,6 +80,10 @@ static int scsi_dev_type_resume(struct device *dev,
dev_dbg(dev, "scsi resume: %d\n", err);
if (err == 0) {
+ bool was_runtime_suspended;
+
+ was_runtime_suspended = pm_runtime_suspended(dev);
+
pm_runtime_disable(dev);
err = pm_runtime_set_active(dev);
pm_runtime_enable(dev);
@@ -93,8 +97,10 @@ static int scsi_dev_type_resume(struct device *dev,
*/
if (!err && scsi_is_sdev_device(dev)) {
struct scsi_device *sdev = to_scsi_device(dev);
-
- blk_set_runtime_active(sdev->request_queue);
+ if (was_runtime_suspended)
+ blk_post_runtime_resume(sdev->request_queue, 0);
+ else
+ blk_set_runtime_active(sdev->request_queue);
}
}
diff --git a/drivers/target/target_core_transport.c
b/drivers/target/target_core_transport.c
index 594b724bbf79..264a822c0bfa 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -3350,6 +3350,7 @@ static void target_tmr_work(struct work_struct *work)
cmd->se_tfo->queue_tm_rsp(cmd);
+ transport_lun_remove_cmd(cmd);
transport_cmd_check_stop_to_fabric(cmd);
return;
RE: [EXTERNAL] Re: [PATCH] x86/Hyper-V: Support for free page reporting
From: Sunil Muthuswamy Sent: Friday, May 22, 2020 9:40 AM > > > > + if (hv_do_hypercall(HV_EXT_CALL_QUERY_CAPABILITIES, NULL, cap) == > > > + HV_STATUS_SUCCESS) > > > > You're using the input page as the output parameter. Ideally we should > > introduce hyperv_pcpu_output_arg page, but that would waste one page per > > cpu just for this one call. > > > > So for now I think this setup is fine, but I would like to add the > > following comment. > > > > /* > > * Repurpose the input_arg page to accept output from Hyper-V for > > * now because this is the only call that needs output from the > > * hypervisor. It should be fixed properly by introducing an > > * output_arg page once we have more places that require output. > > */ > > Sounds good. Will add it in v2. > Note that the only real requirement for the output parameter to hypercalls is that it not cross a page boundary. Since '*cap' is only 64-bits, you can declare it as a static variable or even as a local on the stack. It will naturally be aligned (or can add __aligned(8) to be explicit??), so it won't cross a page boundary. Then you can skip using the per-cpu input arg altogether, along with the associated local_irq_save()/restore(). Michael
RE: [PATCH] thermal: imx8mm: Add get_trend ops
Hi, Daniel > Subject: Re: [PATCH] thermal: imx8mm: Add get_trend ops > > On 13/05/2020 04:58, Anson Huang wrote: > > Add get_trend ops for i.MX8MM thermal to apply fast cooling mechanism, > > when temperature exceeds passive trip point, the highest cooling > > action will be applied, and when temperature drops to lower than the > > margin below passive trip point, the lowest cooling action will be > > applied. > > You are not describing what is the goal of this change. The goal of this change is to make sure whenever temperature exceeds passive trip point, the highest cooling action will be applied immediately, e.g., if there are many cpufreq OPP, the default cooling will be step by step, it will take some more rounds to make cpufreq drop to lowest OPP, while on i.MX, we expect the cpufreq drop to lowest OPP immediately. > > IIUC, the resulting change will be an on/off action. The thermal zone is > mitigated with the highest cooling effect, so the lowest OPP, then the > temperature trend is stable until it goes below the trip - margin where the > mitigation is stopped. Yes, your understanding is correctly, once the temperature exceeds passive trip point, the highest cooling action will be applied immediately and then it will be stable there until temperature drop to trip - margin, then the cooling action will be cancelled, the margin is to avoid the back and forth near the passive trip point. > > Except, I'm missing something, setting a trip point with a 1 hysteresis > and > a cooling map min/max set to the highest opp will result on the same. Yes setting cooling map min/max cooling state to highest OPP will make the highest cooling action applied immediately, and to have the function of cooling action being cancelled when temperature drops to trip - margin, I have to define another trip point, say passive trip point is 85000, and cooling map min/max set to highest OPP in passive trip point then add another trip point named "active" with 75000, and without any cooling map in it, right? If yes, then I think I can try to make the changes in DT instead of thermal driver. Thanks, Anson
Re: [PATCH mmotm] mm/swap: fix livelock in __read_swap_cache_async()
On Thu, 21 May 2020 22:56:20 -0700 (PDT) Hugh Dickins wrote: > I've only seen this livelock on one machine (repeatably, but not to > order), and not fully analyzed it - two processes seen looping around > getting -EEXIST from swapcache_prepare(), I guess a third (at lower > priority? but wanting the same cpu as one of the loopers? preemption > or cond_resched() not enough to let it back in?) set SWAP_HAS_CACHE, > then went off into direct reclaim, scheduled away, and somehow could > not get back to add the page to swap cache and let them all complete. > > Restore the page allocation in __read_swap_cache_async() to before > the swapcache_prepare() call: "mm: memcontrol: charge swapin pages > on instantiation" moved it outside the loop, which indeed looks much > nicer, but exposed this weakness. We used to allocate new_page once > and then keep it across all iterations of the loop: but I think that > just optimizes for a rare case, and complicates the flow, so go with > the new simpler structure, with allocate+free each time around (which > is more considerate use of the memory too). > > Fix the comment on the looping case, which has long been inaccurate: > it's not a racing get_swap_page() that's the problem here. > > Fix the add_to_swap_cache() and mem_cgroup_charge() error recovery: > not swap_free(), but put_swap_page() to undo SWAP_HAS_CACHE, as was > done before; but delete_from_swap_cache() already includes it. > > And one more nit: I don't think it makes any difference in practice, > but remove the "& GFP_KERNEL" mask from the mem_cgroup_charge() call: > add_to_swap_cache() needs that, to convert gfp_mask from user and page > cache allocation (e.g. highmem) to radix node allocation (lowmem), but > we don't need or usually apply that mask when charging mem_cgroup. > > Signed-off-by: Hugh Dickins > --- > Mostly fixing mm-memcontrol-charge-swapin-pages-on-instantiation.patch > but now I see that mm-memcontrol-delete-unused-lrucare-handling.patch > made a further change here (took an arg off the mem_cgroup_charge call): > as is, this patch is diffed to go on top of both of them, and better > that I get it out now for Johannes look at; but could be rediffed for > folding into blah-instantiation.patch later. Thanks - I did the necessary jiggery-pokery to get this into the right place.
Re: [PATCH v2] firmware_loader: change enum fw_opt to u32
On Fri, May 22, 2020 at 04:12:02PM -0700, Scott Branden wrote: > "enum fw_opt" is not used as an enum. > Change fw_opt to u32 as FW_OPT_* values are OR'd together. > > Signed-off-by: Scott Branden Acked-by: Luis Chamberlain Luis
Re: linux-next: build failure after merge of the tip tree
On Fri, May 22, 2020 at 05:49:44PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 22 May 2020 17:17:08 +1000 Stephen Rothwell
> wrote:
> >
> > On Thu, 21 May 2020 18:35:22 +0100 Will Deacon wrote:
> > >
> > > [+Marco and Boris]
> > >
> > > On Fri, May 22, 2020 at 03:31:19AM +1000, Stephen Rothwell wrote:
> > > > After merging the tip tree, all my linux-next builds took signficantly
> > > > longer and used much more memory. In some cases, builds would seg fault
> > > > due to running out of memory :-(
> > > >
> > > > I have eventaully bisected it to commit
> > > >
> > > > cdd28ad2d811 ("READ_ONCE: Use data_race() to avoid KCSAN
> > > > instrumentation")
> > > >
> > > > For my (e.g.) x86_64 allmodconfig builds (cross compiled on PowerPC le,
> > > > -j80) the elapsed time went from around 9 minutes to over 17 minutes
> > > > and the maximum resident size (as reported by /usr/bin/time) from around
> > > > 500M to around 2G (I saw lots of cc1 processes over 2G in size).
> > > >
> > > > For tomorrow's linux-next (well, later today :-() I will revert that
> > > > commit (and its child) when I merge the tip tree.
> > >
> > > Sorry about that, seems we can't avoid running into compiler problems with
> > > this lot. The good news is that there's a series to fix this here:
> > >
> > > https://lore.kernel.org/r/20200521142047.169334-1-el...@google.com
> > >
> > > so hopefully this be fixed in -tip soon (but I agree that reverting the
> > > thing in -next in the meantime makes sense).
> >
> > Unfortunately, the revert didn't work, so instead I have used the tip
> > tree from next-20200518 for today (hopefully this will all be sorted
> > out by Monday).
>
> And the rcu tree has merged part of the tip tree that contains the
> offending commits, so I have used the version fo the rcu tree from
> next-20200519 for today.
Please accept my apologies for my part of this problem! I don't see
the slowdowns on my normal test system (possibly due to gcc 4.8.5),
but I do see them on my laptop.
Marco, Thomas, is there any better setup I can provide Stephen? Or
is the next-20200519 -rcu tree the best we have right now?
Thanx, Paul
Re: [PATCH 3/9] intel_idle: Relocate definitions of cpuidle callbacks
On Thu, Feb 13, 2020 at 11:00:26PM +0100, Rafael J. Wysocki wrote:
> From: "Rafael J. Wysocki"
>
> Move the definitions of intel_idle() and intel_idle_s2idle() before
> the definitions of cpuidle_state structures referring to them to
> avoid having to use additional declarations of them (and drop those
> declarations).
>
> No functional impact.
>
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/idle/intel_idle.c | 154
> ++
> 1 file changed, 75 insertions(+), 79 deletions(-)
>
> diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
> index 5adc058c705d..e0332d567735 100644
> --- a/drivers/idle/intel_idle.c
> +++ b/drivers/idle/intel_idle.c
[]
> +/**
> + * intel_idle - Ask the processor to enter the given idle state.
> + * @dev: cpuidle device of the target CPU.
> + * @drv: cpuidle driver (assumed to point to intel_idle_driver).
> + * @index: Target idle state index.
> + *
> + * Use the MWAIT instruction to notify the processor that the CPU
> represented by
> + * @dev is idle and it can try to enter the idle state corresponding to
> @index.
> + *
> + * If the local APIC timer is not known to be reliable in the target idle
> state,
> + * enable one-shot tick broadcasting for the target CPU before executing
> MWAIT.
> + *
> + * Optionally call leave_mm() for the target CPU upfront to avoid wakeups
> due to
> + * flushing user TLBs.
> + *
> + * Must be called under local_irq_disable().
> + */
> +static __cpuidle int intel_idle(struct cpuidle_device *dev,
> + struct cpuidle_driver *drv, int index)
> +{
> + struct cpuidle_state *state = >states[index];
> + unsigned long eax = flg2MWAIT(state->flags);
> + unsigned long ecx = 1; /* break on interrupt flag */
> + bool uninitialized_var(tick);
This will generate an UBSAN warning because Clang could poison all
uninitialized stack variables to 0xAA due to CONFIG_INIT_STACK_ALL=y, so one
issue is that,
bool uninitialized_var(x);
would always broken on Clang like this,
[ 92.140611] UBSAN: invalid-load in drivers/idle/intel_idle.c:135:7
[ 92.143111] load of value 170 is not a valid value for type 'bool' (aka
'_Bool')
[ 92.145657] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
5.7.0-rc6-next-20200522+ #3
[ 92.147424] Hardware name: HP ProLiant BL660c Gen9, BIOS I38 10/17/2018
[ 92.149869] Call Trace:
[ 92.149869] dump_stack+0x10b/0x17f
[ 92.149869] __ubsan_handle_load_invalid_value+0xd2/0x110
[ 92.149869] intel_idle+0x54/0xf0
[ 92.156202] cpuidle_enter_state+0x120/0x4f0
[ 92.156202] cpuidle_enter+0x5b/0xa0
[ 92.156202] call_cpuidle+0x25/0x50
[ 92.156202] do_idle+0x1eb/0x2c0
[ 92.156202] cpu_startup_entry+0x25/0x30
[ 92.156202] rest_init+0x26f/0x280
[ 92.156202] arch_call_rest_init+0x17/0x1e
[ 92.156202] start_kernel+0x598/0x633
[ 92.156202] x86_64_start_reservations+0x24/0x26
[ 92.156202] x86_64_start_kernel+0x116/0x1c1
[ 92.156202] secondary_startup_64+0xb6/0xc0
However, I am wondering if it is correct to let "tick" uninitialized to begin
with. If this condition is true,
!static_cpu_has(X86_FEATURE_ARAT) && lapic_timer_always_reliable
Then, we could in the final branch to use the uninitialized value.
if (!static_cpu_has(X86_FEATURE_ARAT) && tick)
Isn't that possible?
> + int cpu = smp_processor_id();
> +
> + /*
> + * leave_mm() to avoid costly and often unnecessary wakeups
> + * for flushing the user TLB's associated with the active mm.
> + */
> + if (state->flags & CPUIDLE_FLAG_TLB_FLUSHED)
> + leave_mm(cpu);
> +
> + if (!static_cpu_has(X86_FEATURE_ARAT) && !lapic_timer_always_reliable) {
> + /*
> + * Switch over to one-shot tick broadcast if the target C-state
> + * is deeper than C1.
> + */
> + if ((eax >> MWAIT_SUBSTATE_SIZE) & MWAIT_CSTATE_MASK) {
> + tick = true;
> + tick_broadcast_enter();
> + } else {
> + tick = false;
> + }
> + }
> +
> + mwait_idle_with_hints(eax, ecx);
> +
> + if (!static_cpu_has(X86_FEATURE_ARAT) && tick)
> + tick_broadcast_exit();
> +
> + return index;
> +}
Re: [PATCH 10/10] mm/migrate.c: call detach_page_private to cleanup code
On Fri, 22 May 2020 09:18:25 +0200 Guoqing Jiang
wrote:
> >> - ClearPagePrivate(page);
> >> - set_page_private(newpage, page_private(page));
> >> - set_page_private(page, 0);
> >> - put_page(page);
> >> + set_page_private(newpage, detach_page_private(page));
> > attach_page_private(newpage, detach_page_private(page));
>
> Mattew had suggested it as follows, but not sure if we can reorder of
> the setup of
> the bh and setting PagePrivate, so I didn't want to break the original
> syntax.
>
> @@ -797,11 +797,7 @@ static int __buffer_migrate_page(struct address_space
> *mapping,
> if (rc != MIGRATEPAGE_SUCCESS)
> goto unlock_buffers;
>
> - ClearPagePrivate(page);
> - set_page_private(newpage, page_private(page));
> - set_page_private(page, 0);
> - put_page(page);
> - get_page(newpage);
> + attach_page_private(newpage, detach_page_private(page));
>
> bh = head;
> do {
> @@ -810,8 +806,6 @@ static int __buffer_migrate_page(struct address_space
> *mapping,
>
> } while (bh != head);
>
> - SetPagePrivate(newpage);
> -
> if (mode != MIGRATE_SYNC_NO_COPY)
This is OK - coherency between PG_private and the page's buffer
ring is maintained by holding lock_page().
I have (effectively) applied the above change.
Re: [PATCH net 0/2] rxrpc: Fix a warning and a leak [ver #2]
From: David Howells Date: Sat, 23 May 2020 00:42:32 +0100 > > Here are a couple of fixes for AF_RXRPC: > > (1) Fix an uninitialised variable warning. > > (2) Fix a leak of the ticket on error in rxkad. > > The patches are tagged here: > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > rxrpc-fixes-20200523-v2 Pulled, thanks.
Re: [RFC 1/2] devlink: add simple fw crash helpers
On Fri, May 22, 2020 at 04:23:55PM -0700, Steve deRosier wrote: > Specifically, I don't think we should set a taint flag when a driver > easily handles a routine firmware crash and is confident that things > have come up just fine again. In other words, triggering the taint in > every driver module where it spits out a log comment that it had a > firmware crash and had to recover seems too much. Sure, firmware > shouldn't crash, sure it should be open source so we can fix it, > whatever... those sort of wishful comments simply ignore reality and > our ability to affect effective change. A lot of WiFi firmware crashes > and for well-known cases the drivers handle them well. And in some > cases, not so well and that should be a place the driver should detect > and thus raise a red flag. If a WiFi firmware crash can bring down > the kernel, there's either a major driver bug or some very funky > hardware crap going on. That sort of thing we should be able to > detect, mark with a taint (or something), and fix if within our sphere > of influence. I guess what it comes down to me is how aggressive we > are about setting the flag. Exactly the crux of the issue. I hope that by now we should all be in agreement that at least a firmware crash requiring a reboot is something we should record and inform the user of. A taint seems like a reasonable standard practice for these sorts of things. > I would like there to be a single solution, or a minimized set > depending on what makes sense for the requirements. I haven't had time > to look into the alternatives mentioned here so I don't have an > informed opinion about the solution. I do think Luis is trying to > solve a real problem though. Can we look at this from the point of > view of what are the requirements? What is it we're trying to solve? > > I _think_ that the goal of Luis's original proposal is to report up to > the user, at some future point when the user is interested (because > something super drastic just occured, but long after the fw crash), > that there was a firmware crash without the user having to grep > through all logs on the machine. And then if the user sees that flag > and suspects it, then they can bother to find it in the logs or do > more drastic debugging steps like finding the fw crash in the log and > pulling firmware crash dumps, etc. Yes, that's exactly it. Not all users are clueful to inspect logs. I now have a generic uevent mechanism drafted which sends a uevent for *any* taint. So that is, it does not even depend on this series. But it accomplishes the goal of informing the user of taints. > I think the various alternate solutions are great but perhaps solving > a superset of features (like adding in user-space notifications etc)? > Perhaps different people on these related threads are trying to solve > different problems? The uevent mechanism I implemented (but not yet posted for review) at least sends out a smoke signal. I think that if each subsystem wants to expand on this with dumping facilities that is great too! Luis
[PATCH net 2/2] rxrpc: Fix a memory leak in rxkad_verify_response() [ver #2]
From: Qiushi Wu
A ticket was not released after a call of the function
"rxkad_decrypt_ticket" failed. Thus replace the jump target
"temporary_error_free_resp" by "temporary_error_free_ticket".
Fixes: 8c2f826dc3631 ("rxrpc: Don't put crypto buffers on the stack")
Signed-off-by: Qiushi Wu
Signed-off-by: David Howells
cc: Markus Elfring
---
net/rxrpc/rxkad.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c
index 098f1f9ec53b..52a24d4ef5d8 100644
--- a/net/rxrpc/rxkad.c
+++ b/net/rxrpc/rxkad.c
@@ -1148,7 +1148,7 @@ static int rxkad_verify_response(struct rxrpc_connection
*conn,
ret = rxkad_decrypt_ticket(conn, skb, ticket, ticket_len, _key,
, _abort_code);
if (ret < 0)
- goto temporary_error_free_resp;
+ goto temporary_error_free_ticket;
/* use the session key from inside the ticket to decrypt the
* response */
@@ -1230,7 +1230,6 @@ static int rxkad_verify_response(struct rxrpc_connection
*conn,
temporary_error_free_ticket:
kfree(ticket);
-temporary_error_free_resp:
kfree(response);
temporary_error:
/* Ignore the response packet if we got a temporary error such as
Re: [PATCH v2] kasan: Disable branch tracing for core runtime
On Fri, 22 May 2020 09:52:07 +0200 Marco Elver wrote: > During early boot, while KASAN is not yet initialized, it is possible to > enter reporting code-path and end up in kasan_report(). While > uninitialized, the branch there prevents generating any reports, > however, under certain circumstances when branches are being traced > (TRACE_BRANCH_PROFILING), we may recurse deep enough to cause kernel > reboots without warning. > > To prevent similar issues in future, we should disable branch tracing > for the core runtime. > > Link: https://lore.kernel.org/lkml/20200517011732.GE24705@shao2-debian/ > Reported-by: kernel test robot > Signed-off-by: Marco Elver I assume this affects 5.6 and perhaps earlier kernels? I also assume that a cc:stable is appropriate for this fix?
[PATCH net 1/2] rxrpc: Fix a warning [ver #2]
Fix a warning due to an uninitialised variable.
le included from ../fs/afs/fs_probe.c:11:
../fs/afs/fs_probe.c: In function 'afs_fileserver_probe_result':
../fs/afs/internal.h:1453:2: warning: 'rtt_us' may be used uninitialized in
this function [-Wmaybe-uninitialized]
1453 | printk("[%-6.6s] "FMT"\n", current->comm ,##__VA_ARGS__)
| ^~
../fs/afs/fs_probe.c:35:15: note: 'rtt_us' was declared here
Signed-off-by: David Howells
---
fs/afs/fs_probe.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/afs/fs_probe.c b/fs/afs/fs_probe.c
index 237352d3cb53..37d1bba57b00 100644
--- a/fs/afs/fs_probe.c
+++ b/fs/afs/fs_probe.c
@@ -32,7 +32,7 @@ void afs_fileserver_probe_result(struct afs_call *call)
struct afs_server *server = call->server;
unsigned int server_index = call->server_index;
unsigned int index = call->addr_ix;
- unsigned int rtt_us;
+ unsigned int rtt_us = 0;
bool have_result = false;
int ret = call->error;
[PATCH net 0/2] rxrpc: Fix a warning and a leak [ver #2]
Here are a couple of fixes for AF_RXRPC: (1) Fix an uninitialised variable warning. (2) Fix a leak of the ticket on error in rxkad. The patches are tagged here: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git rxrpc-fixes-20200523-v2 and can also be found on the following branch: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-fixes David --- Qiushi Wu (1): rxrpc: Fix a memory leak in rxkad_verify_response() fs/afs/fs_probe.c | 2 +- net/rxrpc/rxkad.c | 3 +-- 2 files changed, 2 insertions(+), 3 deletions(-)
Re: [PATCH v5 06/11] net: ethernet: mtk-star-emac: new driver
On Fri, May 22, 2020 at 05:06:34PM +0200, Matthias Brugger wrote:
>
>
> On 22/05/2020 14:06, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > This adds the driver for the MediaTek STAR Ethernet MAC currently used
> > on the MT8* SoC family. For now we only support full-duplex.
>
> MT85** SoC family, AFAIU it's not used on MT81** devices. Correct?
>
> >
> > Signed-off-by: Bartosz Golaszewski
> > ---
> > drivers/net/ethernet/mediatek/Kconfig |7 +
> > drivers/net/ethernet/mediatek/Makefile|1 +
> > drivers/net/ethernet/mediatek/mtk_star_emac.c | 1678 +
> > 3 files changed, 1686 insertions(+)
> > create mode 100644 drivers/net/ethernet/mediatek/mtk_star_emac.c
> >
> > diff --git a/drivers/net/ethernet/mediatek/Kconfig
> > b/drivers/net/ethernet/mediatek/Kconfig
> > index 5079b8090f16..500c15e7ea4a 100644
> > --- a/drivers/net/ethernet/mediatek/Kconfig
> > +++ b/drivers/net/ethernet/mediatek/Kconfig
> > @@ -14,4 +14,11 @@ config NET_MEDIATEK_SOC
> > This driver supports the gigabit ethernet MACs in the
> > MediaTek SoC family.
> >
> > +config NET_MEDIATEK_STAR_EMAC
> > + tristate "MediaTek STAR Ethernet MAC support"
> > + select PHYLIB
> > + help
> > + This driver supports the ethernet MAC IP first used on
> > + MediaTek MT85** SoCs.
> > +
> > endif #NET_VENDOR_MEDIATEK
> > diff --git a/drivers/net/ethernet/mediatek/Makefile
> > b/drivers/net/ethernet/mediatek/Makefile
> > index 3362fb7ef859..3a777b4a6cd3 100644
> > --- a/drivers/net/ethernet/mediatek/Makefile
> > +++ b/drivers/net/ethernet/mediatek/Makefile
> > @@ -5,3 +5,4 @@
> >
> > obj-$(CONFIG_NET_MEDIATEK_SOC) += mtk_eth.o
> > mtk_eth-y := mtk_eth_soc.o mtk_sgmii.o mtk_eth_path.o
> > +obj-$(CONFIG_NET_MEDIATEK_STAR_EMAC) += mtk_star_emac.o
> > diff --git a/drivers/net/ethernet/mediatek/mtk_star_emac.c
> > b/drivers/net/ethernet/mediatek/mtk_star_emac.c
> > new file mode 100644
> > index ..789c77af501f
> > --- /dev/null
> > +++ b/drivers/net/ethernet/mediatek/mtk_star_emac.c
> > @@ -0,0 +1,1678 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (c) 2020 MediaTek Corporation
> > + * Copyright (c) 2020 BayLibre SAS
> > + *
> > + * Author: Bartosz Golaszewski
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define MTK_STAR_DRVNAME "mtk_star_emac"
> > +
> > +#define MTK_STAR_WAIT_TIMEOUT 300
> > +#define MTK_STAR_MAX_FRAME_SIZE1514
> > +#define MTK_STAR_SKB_ALIGNMENT 16
> > +#define MTK_STAR_NAPI_WEIGHT 64
> > +#define MTK_STAR_HASHTABLE_MC_LIMIT256
> > +#define MTK_STAR_HASHTABLE_SIZE_MAX512
> > +
> > +/* Normally we'd use NET_IP_ALIGN but on arm64 its value is 0 and it
> > doesn't
> > + * work for this controller.
> > + */
> > +#define MTK_STAR_IP_ALIGN 2
> > +
> > +static const char *const mtk_star_clk_names[] = { "core", "reg", "trans" };
> > +#define MTK_STAR_NCLKS ARRAY_SIZE(mtk_star_clk_names)
> > +
> > +/* PHY Control Register 0 */
> > +#define MTK_STAR_REG_PHY_CTRL0 0x
> > +#define MTK_STAR_BIT_PHY_CTRL0_WTCMD BIT(13)
> > +#define MTK_STAR_BIT_PHY_CTRL0_RDCMD BIT(14)
> > +#define MTK_STAR_BIT_PHY_CTRL0_RWOKBIT(15)
> > +#define MTK_STAR_MSK_PHY_CTRL0_PREGGENMASK(12, 8)
> > +#define MTK_STAR_OFF_PHY_CTRL0_PREG8
> > +#define MTK_STAR_MSK_PHY_CTRL0_RWDATA GENMASK(31, 16)
> > +#define MTK_STAR_OFF_PHY_CTRL0_RWDATA 16
> > +
> > +/* PHY Control Register 1 */
> > +#define MTK_STAR_REG_PHY_CTRL1 0x0004
> > +#define MTK_STAR_BIT_PHY_CTRL1_LINK_ST BIT(0)
> > +#define MTK_STAR_BIT_PHY_CTRL1_AN_EN BIT(8)
> > +#define MTK_STAR_OFF_PHY_CTRL1_FORCE_SPD 9
> > +#define MTK_STAR_VAL_PHY_CTRL1_FORCE_SPD_10M 0x00
> > +#define MTK_STAR_VAL_PHY_CTRL1_FORCE_SPD_100M 0x01
> > +#define MTK_STAR_VAL_PHY_CTRL1_FORCE_SPD_1000M 0x02
> > +#define MTK_STAR_BIT_PHY_CTRL1_FORCE_DPX BIT(11)
> > +#define MTK_STAR_BIT_PHY_CTRL1_FORCE_FC_RX BIT(12)
> > +#define MTK_STAR_BIT_PHY_CTRL1_FORCE_FC_TX BIT(13)
> > +
> > +/* MAC Configuration Register */
> > +#define MTK_STAR_REG_MAC_CFG 0x0008
> > +#define MTK_STAR_OFF_MAC_CFG_IPG 10
> > +#define MTK_STAR_VAL_MAC_CFG_IPG_96BIT GENMASK(4, 0)
> > +#define MTK_STAR_BIT_MAC_CFG_MAXLEN_1522 BIT(16)
> > +#define MTK_STAR_BIT_MAC_CFG_AUTO_PAD BIT(19)
> > +#define MTK_STAR_BIT_MAC_CFG_CRC_STRIP BIT(20)
> > +#define MTK_STAR_BIT_MAC_CFG_VLAN_STRIP
Re: [PATCH] f2fs: avoid inifinite loop to wait for flushing node pages at cp_error
Shutdown test is somtimes hung, since it keeps trying to flush dirty node pages
in an inifinite loop. Let's drop dirty pages at umount in that case.
Signed-off-by: Jaegeuk Kim
---
v2:
- fix typos
fs/f2fs/node.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index e632de10aedab..8c63964a82fd0 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1520,8 +1520,15 @@ static int __write_node_page(struct page *page, bool
atomic, bool *submitted,
trace_f2fs_writepage(page, NODE);
- if (unlikely(f2fs_cp_error(sbi)))
+ if (unlikely(f2fs_cp_error(sbi))) {
+ if (is_sbi_flag_set(sbi, SBI_IS_CLOSE)) {
+ dec_page_count(sbi, F2FS_DIRTY_NODES);
+ up_read(>node_write);
+ unlock_page(page);
+ return 0;
+ }
goto redirty_out;
+ }
if (unlikely(is_sbi_flag_set(sbi, SBI_POR_DOING)))
goto redirty_out;
--
2.27.0.rc0.183.gde8f92d652-goog
Re: [PATCH net 0/3] rxrpc: Fix retransmission timeout and ACK discard
From: David Howells Date: Sat, 23 May 2020 00:26:46 +0100 > David Miller wrote: > >> Pulled, thanks David. > > Thanks. I'll rebase my two extra patches I've just sent you a pull request > for when you've updated the branch. Please respin and fix the Subject line of patch #2 to have a correct rxrpc: prefix. Thanks.
Re: [PATCH net 0/3] rxrpc: Fix retransmission timeout and ACK discard
David Miller wrote: > Pulled, thanks David. Thanks. I'll rebase my two extra patches I've just sent you a pull request for when you've updated the branch. David
Re: [PATCH net 0/3] rxrpc: Fix retransmission timeout and ACK discard [ver #2]
David Howells wrote: > The patches are tagged here: > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > rxrpc-fixes-20200520 Oops. That's the wrong tag. It should be rxrpc-fixes-20200521. David
Re: [RFC 1/2] devlink: add simple fw crash helpers
On Fri, May 22, 2020 at 2:51 PM Luis Chamberlain wrote: > > On Fri, May 22, 2020 at 10:46:07PM +0200, Johannes Berg wrote: > > FWIW, I still completely disagree on that taint. You (Luis) obviously > > have been running into a bug in that driver, I doubt the firmware > > actually managed to wedge the hardware. > > This hasn't happened just once, its happed many times sporadically now, > once a week or two weeks I'd say. And the system isn't being moved > around. > > > But even if it did, that's still not really a kernel taint. The kernel > > itself isn't in any way affected by this. > > Of course it is, a full reboot is required. > > > Yes, the system is in a weird state now. But that's *not* equivalent to > > "kernel tainted". > > Requiring a full reboot is a dire situation to be in, and loosing > connectivity to the point this is not recoverable likewise. > > You guys are making out a taint to be the end of the world. We have a > taint even for a kernel warning, and as others have mentioned mac80211 > already produces these. > I had to go RTFM re: kernel taints because it has been a very long time since I looked at them. It had always seemed to me that most were caused by "kernel-unfriendly" user actions. The most famous of course is loading proprietary modules, out-of-tree modules, forced module loads, etc... Honestly, I had forgotten the large variety of uses of the taint flags. For anyone who hasn't looked at taints recently, I recommend: https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html In light of this I don't object to setting a taint on this anymore. I'm a little uneasy, but I've softened on it now, and now I feel it depends on implementation. Specifically, I don't think we should set a taint flag when a driver easily handles a routine firmware crash and is confident that things have come up just fine again. In other words, triggering the taint in every driver module where it spits out a log comment that it had a firmware crash and had to recover seems too much. Sure, firmware shouldn't crash, sure it should be open source so we can fix it, whatever... those sort of wishful comments simply ignore reality and our ability to affect effective change. A lot of WiFi firmware crashes and for well-known cases the drivers handle them well. And in some cases, not so well and that should be a place the driver should detect and thus raise a red flag. If a WiFi firmware crash can bring down the kernel, there's either a major driver bug or some very funky hardware crap going on. That sort of thing we should be able to detect, mark with a taint (or something), and fix if within our sphere of influence. I guess what it comes down to me is how aggressive we are about setting the flag. I would like there to be a single solution, or a minimized set depending on what makes sense for the requirements. I haven't had time to look into the alternatives mentioned here so I don't have an informed opinion about the solution. I do think Luis is trying to solve a real problem though. Can we look at this from the point of view of what are the requirements? What is it we're trying to solve? I _think_ that the goal of Luis's original proposal is to report up to the user, at some future point when the user is interested (because something super drastic just occured, but long after the fw crash), that there was a firmware crash without the user having to grep through all logs on the machine. And then if the user sees that flag and suspects it, then they can bother to find it in the logs or do more drastic debugging steps like finding the fw crash in the log and pulling firmware crash dumps, etc. I think the various alternate solutions are great but perhaps solving a superset of features (like adding in user-space notifications etc)? Perhaps different people on these related threads are trying to solve different problems? - Steve
Re: [PATCH 0/3] fs: reduce export usage of kerne_read*() calls
Hi Kees,
On 2020-05-22 4:04 p.m., Kees Cook wrote:
On Fri, May 22, 2020 at 03:24:32PM -0700, Scott Branden wrote:
On 2020-05-18 5:37 a.m., Mimi Zohar wrote:
On Sun, 2020-05-17 at 23:22 -0700, Christoph Hellwig wrote:
On Fri, May 15, 2020 at 09:29:33PM +, Luis Chamberlain wrote:
On Wed, May 13, 2020 at 11:17:36AM -0700, Christoph Hellwig wrote:
Can you also move kernel_read_* out of fs.h? That header gets pulled
in just about everywhere and doesn't really need function not related
to the general fs interface.
Sure, where should I dump these?
Maybe a new linux/kernel_read_file.h? Bonus points for a small top
of the file comment explaining the point of the interface, which I
still don't get :)
Instead of rolling your own method of having the kernel read a file,
which requires call specific security hooks, this interface provides a
single generic set of pre and post security hooks. The
kernel_read_file_id enumeration permits the security hook to
differentiate between callers.
To comply with secure and trusted boot concepts, a file cannot be
accessible to the caller until after it has been measured and/or the
integrity (hash/signature) appraised.
In some cases, the file was previously read twice, first to measure
and/or appraise the file and then read again into a buffer for
use. This interface reads the file into a buffer once, calls the
generic post security hook, before providing the buffer to the caller.
(Note using firmware pre-allocated memory might be an issue.)
Partial reading firmware will result in needing to pre-read the entire
file, most likely on the security pre hook.
The entire file may be very large and not fit into a buffer.
Hence one of the reasons for a partial read of the file.
For security purposes, you need to change your code to limit the amount
of data it reads into a buffer at one time to not consume or run out of much
memory.
Hm? That's not how whole-file hashing works. :)
These hooks need to finish their hashing and policy checking before they
can allow the rest of the code to move forward. (That's why it's a
security hook.) If kernel memory utilization is the primary concern,
then sure, things could be rearranged to do partial read and update the
hash incrementally, but the entire file still needs to be locked,
entirely hashed by hook, then read by the caller, then unlocked and
released.
So, if you want to have partial file reads work, you'll need to
rearchitect the way this works to avoid regressing the security coverage
of these operations.
I am not familiar with how the security handling code works at all.
Is the same security check run on files opened from user space?
A file could be huge.
If it assumes there is there is enough memory available to read the
entire file into kernel space
then the improvement below can be left as a memory optimization to be
done in
an independent (or future) patch series.
So, probably, the code will look something like:
file = kernel_open_file_for_reading(...)
file = open...
disallow_writes(file);
while (processed < size-of-file) {
buf = read(file, size...)
security_file_read_partial(buf)
}
ret = security_file_read_finished(file);
if (ret < 0) {
allow_writes(file);
return PTR_ERR(ret);
}
return file;
while (processed < size-of-file) {
buf = read(file, size...)
firmware_send_partial(buf);
}
kernel_close_file_for_reading(file)
allow_writes(file);
[PATCH net 0/2] rxrpc: Fix a warning and a leak
Here are a couple of fixes for AF_RXRPC: (1) Fix an uninitialised variable warning. (2) Fix a leak of the ticket on error in rxkad. The patches are tagged here: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git rxrpc-fixes-20200523 and can also be found on the following branch: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-fixes and follows on from rxrpc-fixes-20200521. David --- Qiushi Wu (1): A ticket was not released after a call of the function fs/afs/fs_probe.c| 18 ++-- fs/afs/vl_probe.c| 18 ++-- include/net/af_rxrpc.h | 2 +- include/trace/events/rxrpc.h | 52 +--- net/rxrpc/Makefile | 1 + net/rxrpc/ar-internal.h | 25 -- net/rxrpc/call_accept.c | 2 +- net/rxrpc/call_event.c | 22 ++--- net/rxrpc/input.c| 44 -- net/rxrpc/misc.c | 5 -- net/rxrpc/output.c | 9 +- net/rxrpc/peer_event.c | 46 -- net/rxrpc/peer_object.c | 12 +-- net/rxrpc/proc.c | 8 +- net/rxrpc/rtt.c | 195 +++ net/rxrpc/rxkad.c| 3 +- net/rxrpc/sendmsg.c | 26 ++ net/rxrpc/sysctl.c | 9 -- 18 files changed, 336 insertions(+), 161 deletions(-) create mode 100644 net/rxrpc/rtt.c
[PATCH net 2/2] A ticket was not released after a call of the function
From: Qiushi Wu
"rxkad_decrypt_ticket" failed. Thus replace the jump target
"temporary_error_free_resp" by "temporary_error_free_ticket".
Fixes: 8c2f826dc3631 ("rxrpc: Don't put crypto buffers on the stack")
Signed-off-by: Qiushi Wu
Signed-off-by: David Howells
cc: Markus Elfring
---
net/rxrpc/rxkad.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c
index 098f1f9ec53b..52a24d4ef5d8 100644
--- a/net/rxrpc/rxkad.c
+++ b/net/rxrpc/rxkad.c
@@ -1148,7 +1148,7 @@ static int rxkad_verify_response(struct rxrpc_connection
*conn,
ret = rxkad_decrypt_ticket(conn, skb, ticket, ticket_len, _key,
, _abort_code);
if (ret < 0)
- goto temporary_error_free_resp;
+ goto temporary_error_free_ticket;
/* use the session key from inside the ticket to decrypt the
* response */
@@ -1230,7 +1230,6 @@ static int rxkad_verify_response(struct rxrpc_connection
*conn,
temporary_error_free_ticket:
kfree(ticket);
-temporary_error_free_resp:
kfree(response);
temporary_error:
/* Ignore the response packet if we got a temporary error such as
[PATCH net 1/2] rxrpc: Fix a warning
Fix a warning due to an uninitialised variable.
le included from ../fs/afs/fs_probe.c:11:
../fs/afs/fs_probe.c: In function 'afs_fileserver_probe_result':
../fs/afs/internal.h:1453:2: warning: 'rtt_us' may be used uninitialized in
this function [-Wmaybe-uninitialized]
1453 | printk("[%-6.6s] "FMT"\n", current->comm ,##__VA_ARGS__)
| ^~
../fs/afs/fs_probe.c:35:15: note: 'rtt_us' was declared here
Signed-off-by: David Howells
---
fs/afs/fs_probe.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/afs/fs_probe.c b/fs/afs/fs_probe.c
index 237352d3cb53..37d1bba57b00 100644
--- a/fs/afs/fs_probe.c
+++ b/fs/afs/fs_probe.c
@@ -32,7 +32,7 @@ void afs_fileserver_probe_result(struct afs_call *call)
struct afs_server *server = call->server;
unsigned int server_index = call->server_index;
unsigned int index = call->addr_ix;
- unsigned int rtt_us;
+ unsigned int rtt_us = 0;
bool have_result = false;
int ret = call->error;
Re: [PATCH] net: sun: fix missing release regions in cas_init_one().
From: wu000...@umn.edu
Date: Fri, 22 May 2020 16:50:27 -0500
> From: Qiushi Wu
>
> In cas_init_one(), "pdev" is requested by "pci_request_regions", but it
> was not released after a call of the function “pci_write_config_byte”
> failed. Thus replace the jump target “err_write_cacheline” by
> "err_out_free_res".
>
> Fixes: 1f26dac32057 ("[NET]: Add Sun Cassini driver.")
> Signed-off-by: Qiushi Wu
Applied, thank you.
Re: [RESEND PATCH v14 04/11] pwm: clps711x: Cast period to u32 before use as divisor
On Fri, May 22, 2020 at 10:37:38AM +0100, Daniel Thompson wrote:
> On Thu, May 21, 2020 at 01:25:25PM -0700, Guru Das Srinagesh wrote:
> > On Thu, May 21, 2020 at 11:19:34AM +0100, Daniel Thompson wrote:
> > > On Wed, May 20, 2020 at 03:55:57PM -0700, Guru Das Srinagesh wrote:
> > > > Since the PWM framework is switching struct pwm_args.period's datatype
> > > > to u64, prepare for this transition by typecasting it to u32.
> > > >
> > > > Also, since the dividend is still a 32-bit number, any divisor greater
> > > > than the numerator will cause the quotient to be zero, so return 0 in
> > > > that case to efficiently skip the division.
> > > >
> > > > Signed-off-by: Guru Das Srinagesh
> > > > ---
> > > > drivers/pwm/pwm-clps711x.c | 5 -
> > > > 1 file changed, 4 insertions(+), 1 deletion(-)> > >
> > > > diff --git a/drivers/pwm/pwm-clps711x.c b/drivers/pwm/pwm-clps711x.c
> > > > index 924d39a..da771b1 100644
> > > > --- a/drivers/pwm/pwm-clps711x.c
> > > > +++ b/drivers/pwm/pwm-clps711x.c
> > > > @@ -43,7 +43,10 @@ static void clps711x_pwm_update_val(struct
> > > > clps711x_chip *priv, u32 n, u32 v)
> > > > static unsigned int clps711x_get_duty(struct pwm_device *pwm, unsigned
> > > > int v)
> > > > {
> > > > /* Duty cycle 0..15 max */
> > > > - return DIV_ROUND_CLOSEST(v * 0xf, pwm->args.period);
> > > > + if (pwm->args.period > (v * 0xf))
> > > > + return 0;
> > >
> > > This doesn't look right to me.
> > >
> > > DIV_ROUND_CLOSEST() does rounded division and the short circuit doesn't
> > > implement that.
> >
> > My initial patch [1] was to simply use DIV64_U64_ROUND_CLOSEST(), but I
> > got review feedback to add a short-circuit (same thread, [2]). I feel
> > like I should skip the short-circuiting and type casting and simply just
> > use DIV64_U64_ROUND_CLOSEST() - what do you think?
>
> A trivial review of pwm-clps711x.c suggests that the period is always
> 32-bit anyway so why not just throw away the short circuit entirely and
> replace with a comment saying that CLPS711X has a hard coded period
> that is always >10 ?
Sorry, I don't follow the significance of 10 - could you please
explain?
Just to clarify, what I was saying in my previous email was the
following: I think it might be simpler to just throw away the short
circuit and just do:
s/DIV_ROUND_CLOSEST/DIV64_U64_ROUND_CLOSEST
like in another patch in this series [1]. That should handle the
rounding properly as per design. Is that okay?
[1]
https://lore.kernel.org/lkml/ca783e0f5ff7b517ce0854908f0e89b07551bfe5.1588616856.git.gu...@codeaurora.org/
Thank you.
Guru Das.
Re: KASAN: slab-out-of-bounds Read in dlfb_usb_probe
syzbot has bisected this bug to:
commit f2c2e717642c66f7fe7e5dd69b2e8ff5849f4d10
Author: Andrey Konovalov
Date: Mon Feb 24 16:13:03 2020 +
usb: gadget: add raw-gadget interface
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10510cba10
start commit: 051143e1 Merge tag 'apparmor-pr-2020-05-21' of git://git.k..
git tree: upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=12510cba10
console output: https://syzkaller.appspot.com/x/log.txt?x=14510cba10
kernel config: https://syzkaller.appspot.com/x/.config?x=b3368ce0cc5f5ace
dashboard link: https://syzkaller.appspot.com/bug?extid=ed94135f896a14d75284
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=103d795e10
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=143d795e10
Reported-by: syzbot+ed94135f896a14d75...@syzkaller.appspotmail.com
Fixes: f2c2e717642c ("usb: gadget: add raw-gadget interface")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
sound/soc/jz4740/jz4740-i2s.c:491:34: warning: unused variable 'jz4770_i2s_soc_info'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 444565650a5fe9c63ddf153e6198e31705dedeb2
commit: a3434a497a2f33324e0f47bc1500a400959b4b25 ASoC: jz4740-i2s: Add support
for the JZ4770
date: 8 weeks ago
config: mips-randconfig-r014-20200522 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
3393cc4cebf9969db94dc424b7a2b6195589c33b)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install mips cross compiling tool for clang build
# apt-get install binutils-mips-linux-gnu
git checkout a3434a497a2f33324e0f47bc1500a400959b4b25
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>, old ones prefixed by <<):
sound/soc/jz4740/jz4740-i2s.c:463:34: warning: unused variable
'jz4740_i2s_soc_info' [-Wunused-const-variable]
static const struct i2s_soc_info jz4740_i2s_soc_info = {
^
sound/soc/jz4740/jz4740-i2s.c:468:34: warning: unused variable
'jz4760_i2s_soc_info' [-Wunused-const-variable]
static const struct i2s_soc_info jz4760_i2s_soc_info = {
^
>> sound/soc/jz4740/jz4740-i2s.c:491:34: warning: unused variable
>> 'jz4770_i2s_soc_info' [-Wunused-const-variable]
static const struct i2s_soc_info jz4770_i2s_soc_info = {
^
sound/soc/jz4740/jz4740-i2s.c:496:34: warning: unused variable
'jz4780_i2s_soc_info' [-Wunused-const-variable]
static const struct i2s_soc_info jz4780_i2s_soc_info = {
^
4 warnings generated.
vim +/jz4770_i2s_soc_info +491 sound/soc/jz4740/jz4740-i2s.c
490
> 491 static const struct i2s_soc_info jz4770_i2s_soc_info = {
492 .version = JZ_I2S_JZ4770,
493 .dai = _i2s_dai,
494 };
495
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v2 0/3] bridge: mrp: Add br_mrp_unique_ifindex function
From: Horatiu Vultur Date: Thu, 21 May 2020 23:19:04 + > This patch series adds small fixes to MRP implementation. > The following are fixed in this patch series: > - now is not allow to add the same port to multiple MRP rings > - remove unused variable > - restore the port state according to the bridge state when the MRP instance > is deleted > > v2: > - use rtnl_dereference instead of rcu_dereference in the first patch Series applied to net-next, thanks.
[GIT PULL] cpupower update for Linux 5.8-rc1
Hi Rafael,
Please pull the following cpupower update for Linux 5.8-rc1.
This cpupower update for Linux 5.8-rc1 consists of a single
patch to fix coccicheck unneeded semicolon warning.
diff is attached.
thanks,
-- Shuah
The following changes since commit 0e698dfa282211e414076f9dc7e83c1c288314fd:
Linux 5.7-rc4 (2020-05-03 14:56:04 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux
tags/linux-cpupower-5.8-rc1
for you to fetch changes up to 7b0bf99b9ee497cc0f079472566aff716d033d43:
cpupower: Remove unneeded semicolon (2020-05-08 10:13:26 -0600)
linux-cpupower-5.8-rc1
This cpupower update for Linux 5.8-rc1 consists of a single
patch to fix coccicheck unneeded semicolon warning.
Zou Wei (1):
cpupower: Remove unneeded semicolon
tools/power/cpupower/utils/cpupower-info.c| 2 +-
tools/power/cpupower/utils/cpupower-set.c | 2 +-
tools/power/cpupower/utils/idle_monitor/amd_fam14h_idle.c | 2 +-
tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c | 6 +++---
tools/power/cpupower/utils/idle_monitor/hsw_ext_idle.c| 2 +-
tools/power/cpupower/utils/idle_monitor/nhm_idle.c| 2 +-
tools/power/cpupower/utils/idle_monitor/snb_idle.c| 2 +-
7 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/tools/power/cpupower/utils/cpupower-info.c b/tools/power/cpupower/utils/cpupower-info.c
index d3755ea70d4d..0ba61a2c4d81 100644
--- a/tools/power/cpupower/utils/cpupower-info.c
+++ b/tools/power/cpupower/utils/cpupower-info.c
@@ -62,7 +62,7 @@ int cmd_info(int argc, char **argv)
default:
print_wrong_arg_exit();
}
- };
+ }
if (!params.params)
params.params = 0x7;
diff --git a/tools/power/cpupower/utils/cpupower-set.c b/tools/power/cpupower/utils/cpupower-set.c
index 3cca6f715dd9..052044d7e012 100644
--- a/tools/power/cpupower/utils/cpupower-set.c
+++ b/tools/power/cpupower/utils/cpupower-set.c
@@ -72,7 +72,7 @@ int cmd_set(int argc, char **argv)
default:
print_wrong_arg_exit();
}
- };
+ }
if (!params.params)
print_wrong_arg_exit();
diff --git a/tools/power/cpupower/utils/idle_monitor/amd_fam14h_idle.c b/tools/power/cpupower/utils/idle_monitor/amd_fam14h_idle.c
index 20f46348271b..5edd35bd9ee9 100644
--- a/tools/power/cpupower/utils/idle_monitor/amd_fam14h_idle.c
+++ b/tools/power/cpupower/utils/idle_monitor/amd_fam14h_idle.c
@@ -117,7 +117,7 @@ static int amd_fam14h_get_pci_info(struct cstate *state,
break;
default:
return -1;
- };
+ }
return 0;
}
diff --git a/tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c b/tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c
index a65f7d011513..8b42c2f0a5b0 100644
--- a/tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c
+++ b/tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c
@@ -53,7 +53,7 @@ static int cpuidle_start(void)
dprint("CPU %d - State: %d - Val: %llu\n",
cpu, state, previous_count[cpu][state]);
}
- };
+ }
return 0;
}
@@ -72,7 +72,7 @@ static int cpuidle_stop(void)
dprint("CPU %d - State: %d - Val: %llu\n",
cpu, state, previous_count[cpu][state]);
}
- };
+ }
return 0;
}
@@ -172,7 +172,7 @@ static struct cpuidle_monitor *cpuidle_register(void)
cpuidle_cstates[num].id = num;
cpuidle_cstates[num].get_count_percent =
cpuidle_get_count_percent;
- };
+ }
/* Free this at program termination */
previous_count = malloc(sizeof(long long *) * cpu_count);
diff --git a/tools/power/cpupower/utils/idle_monitor/hsw_ext_idle.c b/tools/power/cpupower/utils/idle_monitor/hsw_ext_idle.c
index 97ad3233a521..55e55b6b42f9 100644
--- a/tools/power/cpupower/utils/idle_monitor/hsw_ext_idle.c
+++ b/tools/power/cpupower/utils/idle_monitor/hsw_ext_idle.c
@@ -79,7 +79,7 @@ static int hsw_ext_get_count(enum intel_hsw_ext_id id, unsigned long long *val,
break;
default:
return -1;
- };
+ }
if (read_msr(cpu, msr, val))
return -1;
return 0;
diff --git a/tools/power/cpupower/utils/idle_monitor/nhm_idle.c b/tools/power/cpupower/utils/idle_monitor/nhm_idle.c
index 114271165182..16eaf006f61f 100644
--- a/tools/power/cpupower/utils/idle_monitor/nhm_idle.c
+++ b/tools/power/cpupower/utils/idle_monitor/nhm_idle.c
@@ -91,7 +91,7 @@ static int nhm_get_count(enum intel_nhm_id id, unsigned long long *val,
break;
default:
return -1;
- };
+ }
if (read_msr(cpu, msr, val))
return -1;
diff --git a/tools/power/cpupower/utils/idle_monitor/snb_idle.c b/tools/power/cpupower/utils/idle_monitor/snb_idle.c
index df8b223cc096..811d63ab17a7 100644
--- a/tools/power/cpupower/utils/idle_monitor/snb_idle.c
+++ b/tools/power/cpupower/utils/idle_monitor/snb_idle.c
@@ -77,7 +77,7 @@ static int
Re: [PATCH net-next v3 0/2] DP83869 Enhancements
From: Dan Murphy Date: Thu, 21 May 2020 12:47:36 -0500 > These are improvements to the DP83869 Ethernet PHY driver. OP-mode and port > mirroring may be strapped on the device but the software only retrives these > settings from the device tree. Reading the straps and initializing the > associated stored variables so when setting the PHY up and down the PHY's > configuration values will be retained. Series applied, thank you.
