include/asm-generic/irqflags.h:47:9: sparse: sparse: context imbalance in 'cm_queue_work_unlock' - unexpected unlock
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: b29482fde649c72441d5478a4ea2c52c56d97a5e
commit: e83f195aa45c1ffd73b3a950a887e41c260cf194 RDMA/cm: Pull duplicated code
into cm_queue_work_unlock()
date: 4 weeks ago
config: sh-randconfig-s032-20200611 (attached as .config)
compiler: sh4-linux-gcc (GCC) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-250-g42323db3-dirty
git checkout e83f195aa45c1ffd73b3a950a887e41c260cf194
# save the attached .config to linux build tree
make W=1 C=1 ARCH=sh CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/infiniband/core/cm.c:1297:21: sparse: sparse: cast from restricted
__be32
>> include/asm-generic/irqflags.h:47:9: sparse: sparse: context imbalance in
>> 'cm_queue_work_unlock' - unexpected unlock
drivers/infiniband/core/cm.c:2043:12: sparse: sparse: context imbalance in
'cm_req_handler' - different lock contexts for basic block
drivers/infiniband/core/cm.c:2422:12: sparse: sparse: context imbalance in
'cm_rep_handler' - different lock contexts for basic block
drivers/infiniband/core/cm.c:2533:12: sparse: sparse: context imbalance in
'cm_establish_handler' - different lock contexts for basic block
drivers/infiniband/core/cm.c:2556:12: sparse: sparse: context imbalance in
'cm_rtu_handler' - different lock contexts for basic block
drivers/infiniband/core/cm.c:2770:12: sparse: sparse: context imbalance in
'cm_dreq_handler' - different lock contexts for basic block
drivers/infiniband/core/cm.c:2847:12: sparse: sparse: context imbalance in
'cm_drep_handler' - different lock contexts for basic block
drivers/infiniband/core/cm.c:2995:12: sparse: sparse: context imbalance in
'cm_rej_handler' - wrong count at exit
drivers/infiniband/core/cm.c:3153:12: sparse: sparse: context imbalance in
'cm_mra_handler' - different lock contexts for basic block
drivers/infiniband/core/cm.c:3271:12: sparse: sparse: context imbalance in
'cm_lap_handler' - different lock contexts for basic block
drivers/infiniband/core/cm.c:3360:12: sparse: sparse: context imbalance in
'cm_apr_handler' - different lock contexts for basic block
drivers/infiniband/core/cm.c:3405:12: sparse: sparse: context imbalance in
'cm_timewait_handler' - different lock contexts for basic block
vim +/cm_queue_work_unlock +47 include/asm-generic/irqflags.h
aafe4dbed0bf6c Arnd Bergmann 2009-05-13 42
aafe4dbed0bf6c Arnd Bergmann 2009-05-13 43 /* unconditionally enable
interrupts */
df9ee29270c11d David Howells 2010-10-07 44 #ifndef arch_local_irq_enable
df9ee29270c11d David Howells 2010-10-07 45 static inline void
arch_local_irq_enable(void)
aafe4dbed0bf6c Arnd Bergmann 2009-05-13 46 {
df9ee29270c11d David Howells 2010-10-07 @47
arch_local_irq_restore(ARCH_IRQ_ENABLED);
aafe4dbed0bf6c Arnd Bergmann 2009-05-13 48 }
aafe4dbed0bf6c Arnd Bergmann 2009-05-13 49 #endif
aafe4dbed0bf6c Arnd Bergmann 2009-05-13 50
:: The code at line 47 was first introduced by commit
:: df9ee29270c11dba7d0fe0b83ce47a4d8e8d2101 Fix IRQ flag handling naming
:: TO: David Howells
:: CC: David Howells
---
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] ARM: dts: rockchip: Add marvell BT irq config
On 6/11/20 4:06 AM, Abhishek Pandit-Subedi wrote:
> Veyron Jaq and Mighty both use the Marvel 8897 WiFi+BT chip. Add wakeup
> and pinctrl block to devicetree so the btmrvl driver can correctly
> configure the wakeup interrupt.
>
> Signed-off-by: Abhishek Pandit-Subedi
> Reviewed-by: Reviewed-by: Douglas Anderson
> ---
> The Veyron Mighty Chromebook (rk3288 based board) is missing the wake
> configuration for Bluetooth. Without this change, the wake irq was not
> configurable and wake on Bluetooth was broken.
>
> I verified this change with additional changes in the Bluetooth driver
> (the series is at https://patchwork.kernel.org/cover/11599101/). The
> driver changes are not necessary for this dts change and shouldn't block
> it.
>
>
> arch/arm/boot/dts/rk3288-veyron-jaq.dts | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> index 171ba6185b6d39..976c0c17a71199 100644
> --- a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> +++ b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> @@ -51,6 +51,21 @@ {
> _bus4>;
> };
>
> + {
For nodes:
Sort things without reg alphabetical first,
then sort the rest by reg address.
goes above
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + btmrvl: btmrvl@2 {
> + compatible = "marvell,sd8897-bt";
> + reg = <2>;
> + interrupt-parent = <>;
> + interrupts = ;
> + marvell,wakeup-pin = /bits/ 16 <13>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_host_wake_l>;
> + };
> +};
> +
> _5v {
> enable-active-high;
> gpio = < RK_PC5 GPIO_ACTIVE_HIGH>;
>
Re: [PATCH v2] powerpc: Remove inaccessible CMDLINE default
Le 11/06/2020 à 05:41, Chris Packham a écrit :
Since commit cbe46bd4f510 ("powerpc: remove CONFIG_CMDLINE #ifdef mess")
CONFIG_CMDLINE has always had a value regardless of CONFIG_CMDLINE_BOOL.
For example:
$ make ARCH=powerpc defconfig
$ cat .config
# CONFIG_CMDLINE_BOOL is not set
CONFIG_CMDLINE=""
When enabling CONFIG_CMDLINE_BOOL this value is kept making the 'default
"..." if CONFIG_CMDLINE_BOOL' ineffective.
$ ./scripts/config --enable CONFIG_CMDLINE_BOOL
$ cat .config
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE=""
Remove CONFIG_CMDLINE_BOOL and the inaccessible default.
You also have to remove all CONFIG_CMDLINE_BOOL from the defconfigs
Christophe
Signed-off-by: Chris Packham
Reviewed-by: Christophe Leroy
---
It took me a while to get round to sending a v2, for a refresher v1 can be
found here:
http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20190802050232.22978-1-chris.pack...@alliedtelesis.co.nz/
Changes in v2:
- Rebase on top of Linus's tree
- Fix some typos in commit message
- Add review from Christophe
- Remove CONFIG_CMDLINE_BOOL
arch/powerpc/Kconfig | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9fa23eb320ff..51abc59c3334 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -859,12 +859,8 @@ config PPC_DENORMALISATION
Add support for handling denormalisation of single precision
values. Useful for bare metal only. If unsure say Y here.
-config CMDLINE_BOOL
- bool "Default bootloader kernel arguments"
-
config CMDLINE
- string "Initial kernel command string" if CMDLINE_BOOL
- default "console=ttyS0,9600 console=tty0 root=/dev/sda2" if CMDLINE_BOOL
+ string "Initial kernel command string"
default ""
help
On some platforms, there is currently no way for the boot loader to
[PATCH 2/2] mtd: rawnand: brcmnand: Ecc error handling on EDU transfers
Implemented ECC correctable and uncorrectable error handling for EDU
reads. If ECC correctable bitflips are encountered on EDU transfer,
read page again using pio, This is needed due to a controller lmitation
where read and corrected data is not transferred to the DMA buffer on ECC
errors. This holds true for ECC correctable errors beyond set threshold.
Fixes: a5d53ad26a8b ("mtd: rawnand: brcmnand: Add support for flash-edu for dma
transfers")
Signed-off-by: Kamal Dasu
---
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 26
1 file changed, 26 insertions(+)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index 0c1d6e543586..d7daa83c8a58 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -1855,6 +1855,22 @@ static int brcmnand_edu_trans(struct brcmnand_host
*host, u64 addr, u32 *buf,
edu_writel(ctrl, EDU_STOP, 0); /* force stop */
edu_readl(ctrl, EDU_STOP);
+ if (ret == 0 && edu_cmd == EDU_CMD_READ) {
+ u64 err_addr = 0;
+
+ /*
+* check for ecc errors here, subpage ecc erros are
+* retained in ecc error addr register
+*/
+ err_addr = brcmnand_get_uncorrecc_addr(ctrl);
+ if (!err_addr) {
+ err_addr = brcmnand_get_correcc_addr(ctrl);
+ if (err_addr)
+ ret = -EUCLEAN;
+ } else
+ ret = -EBADMSG;
+ }
+
return ret;
}
@@ -2058,6 +2074,7 @@ static int brcmnand_read(struct mtd_info *mtd, struct
nand_chip *chip,
u64 err_addr = 0;
int err;
bool retry = true;
+ bool edu_read = false;
dev_dbg(ctrl->dev, "read %llx -> %p\n", (unsigned long long)addr, buf);
@@ -2075,6 +2092,10 @@ static int brcmnand_read(struct mtd_info *mtd, struct
nand_chip *chip,
else
return -EIO;
}
+
+ if (has_edu(ctrl))
+ edu_read = true;
+
} else {
if (oob)
memset(oob, 0x99, mtd->oobsize);
@@ -2122,6 +2143,11 @@ static int brcmnand_read(struct mtd_info *mtd, struct
nand_chip *chip,
if (mtd_is_bitflip(err)) {
unsigned int corrected = brcmnand_count_corrected(ctrl);
+ /* in case of edu correctable error we read again using pio */
+ if (edu_read)
+ err = brcmnand_read_by_pio(mtd, chip, addr, trans, buf,
+ oob, _addr);
+
dev_dbg(ctrl->dev, "corrected error at 0x%llx\n",
(unsigned long long)err_addr);
mtd->ecc_stats.corrected += corrected;
--
2.17.1
[PATCH 1/2] mtd: rawnand: brcmnand: Don't default to edu transfer
When flash-dma is absent do not default to using flash-edu.
Make sure flash-edu is enabled before setting EDU transfer
function.
Fixes: a5d53ad26a8b ("mtd: rawnand: brcmnand: Add support for flash-edu for dma
transfers")
Signed-off-by: Kamal Dasu
---
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index 8f9ffb46a09f..0c1d6e543586 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -2953,8 +2953,9 @@ int brcmnand_probe(struct platform_device *pdev, struct
brcmnand_soc *soc)
if (ret < 0)
goto err;
- /* set edu transfer function to call */
- ctrl->dma_trans = brcmnand_edu_trans;
+ if (has_edu(ctrl))
+ /* set edu transfer function to call */
+ ctrl->dma_trans = brcmnand_edu_trans;
}
/* Disable automatic device ID config, direct addressing */
--
2.17.1
Re: [PATCH v6 6/6] blktrace: fix debugfs use after free
On Wed, Jun 10, 2020 at 11:31:16PM +, Luis Chamberlain wrote: > On Wed, Jun 10, 2020 at 09:52:13PM +, Luis Chamberlain wrote: > > diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c > > index 7ff2ea5cd05e..5cea04c05e09 100644 > > --- a/kernel/trace/blktrace.c > > +++ b/kernel/trace/blktrace.c > > @@ -524,10 +524,16 @@ static int do_blk_trace_setup(struct request_queue > > *q, char *name, dev_t dev, > > if (!bt->msg_data) > > goto err; > > > > - ret = -ENOENT; > > - > > - dir = debugfs_lookup(buts->name, blk_debugfs_root); > > - if (!dir) > > + /* > > +* When tracing whole make_request drivers (multiqueue) block devices, > > +* reuse the existing debugfs directory created by the block layer on > > +* init. For request-based block devices, all partitions block devices, > > +* and scsi-generic block devices we create a temporary new debugfs > > +* directory that will be removed once the trace ends. > > +*/ > > + if (queue_is_mq(q)) > > And this should be instead: > > if (queue_is_mq(q) && bdev && bdev == bdev->bd_contains) Yes. But I think keeping the queue_is_mq out and always creating the debugfs dir is an improvement as we'll sooner or later grow more debugfs files and than the whole set of problmes reappears. But I'd be fine with doing the above in the first patch that is tiny and backportable, and then have another patch that always creates the debugfs directory.
[PATCH] pinctrl: meson: fix drive strength register and bit calculation
On Wed, Jun 10, 2020 at 03:09:42PM +0200, Jerome Brunet wrote:
>
> On Wed 10 Jun 2020 at 06:13, hhk7...@gmail.com wrote:
>
> > From: Hyeonki Hong
> >
> > If a GPIO bank has greater than 16 pins, PAD_DS_REG is split into two
> > registers. However, when register and bit were calculated, the first
> > register defined in the bank was used, and the bit was calculated based
> > on the first pin. This causes problems in setting the driving strength.
> >
> > Solved the problem by changing the bit using a mask and selecting the
> > next register when the bit exceeds 15.
>
> This fixes the case of GPIOX on g12 which goes up to 18 yes but the same
> problem will happen again a if bank ever goes past 31 pins. In such case
> the problem would apply to all reg types.
>
> I would prefer if it was solved in a more generic fashion, like defining
> a "stride" table with the values of each reg type. This table can common
> to all aml SoCs for now but eventually it probably need to be SoC
> specific.
>
> This would allow to :
> A) handle the case you are reporting in a generic (future proof) way
> B) remove the weird "bit = bit << 1;" calc in place in the get/set of
> the drive strengh pinconf
If all amlogic SoC has same register style, I think the code below is fine.
static const unsigned int meson_bit_strides[] = {
0, 0, 0, 0, 0, 1, 0
};
static void meson_calc_reg_and_bit(struct meson_bank *bank, unsigned int pin,
enum meson_reg_type reg_type,
unsigned int *reg, unsigned int *bit)
{
struct meson_reg_desc *desc = >regs[reg_type];
*bit = (desc->bit + pin - bank->first) << meson_bit_strides[reg_type];
*reg = (desc->reg + (*bit / 32)) * 4;
*bit &= 0x1f;
}
How about this?
> >
> > Signed-off-by: Hyeonki Hong
> > ---
> > drivers/pinctrl/meson/pinctrl-meson.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/pinctrl/meson/pinctrl-meson.c
> > b/drivers/pinctrl/meson/pinctrl-meson.c
> > index bbc919bef2bf..ef66239b7df5 100644
> > --- a/drivers/pinctrl/meson/pinctrl-meson.c
> > +++ b/drivers/pinctrl/meson/pinctrl-meson.c
> > @@ -98,6 +98,13 @@ static void meson_calc_reg_and_bit(struct meson_bank
> > *bank, unsigned int pin,
> >
> > *reg = desc->reg * 4;
> > *bit = desc->bit + pin - bank->first;
> > +
> > + if (reg_type == REG_DS) {
> > + if (*bit > 15) {
> > + *bit &= 0xf;
> > + *reg += 4;
> > + }
> > + }
> > }
> >
> > static int meson_get_groups_count(struct pinctrl_dev *pcdev)
>
[PATCH v2 1/1] checkpatch: add check for NONNETWORKING_BLOCK_COMMENT_STYLE
NETWORKING_BLOCK_COMMENT_STYLE is supported by checkpatch but there
doesn't seem to be any check for the standard block comment style.
Add support for NONNETWORKING_BLOCK_COMMENT_STYLE to check for empty /*
on first line of non-networking block comments.
Signed-off-by: Scott Branden
---
Changes since v1:
-
Do file/patch test and used CHK on file as suggested by Joe Perches.
---
scripts/checkpatch.pl | 12
1 file changed, 12 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index d4860972c721..45c71e7543f7 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3408,6 +3408,18 @@ sub process {
"networking block comments don't use an empty /*
line, use /* Comment...\n" . $hereprev);
}
+# Non-Networking with an empty initial /*
+ if ($realfile !~ m@^(drivers/net/|net/)@ &&
+ $prevrawline =~ /^\+[ \t]*\/\*[ \t]/ &&
+ $prevrawline !~ /\*\/[ \t]*$/ &&#no trailing */
+ $rawline =~ /^\+[ \t]*\*/ &&
+ $realline > 2) {
+ my $msg_level = \
+ $msg_level = \ if ($file);
+ &{$msg_level}("NONNETWORKING_BLOCK_COMMENT_STYLE",
+ "non-networking block comments use an
empty /* on first line\n" . $hereprev);
+ }
+
# Block comments use * on subsequent lines
if ($prevline =~ /$;[ \t]*$/ && #ends in comment
$prevrawline =~ /^\+.*?\/\*/ && #starting /*
--
2.17.1
Re: [RFC PATCH 0/3] Add Documentation for /proc/cpuinfo flags
On Wed, Jun 10, 2020 at 01:06:58PM -0700, Kyung Min Park wrote: > This RFC series has been reviewed by Dave Hansen. Then why isn't there a "Reviewed-by:" line with his name on it on the patches? Come on, you all know how to do this properly...
[git pull] m68knommu changes for v5.8
Hi Linus,
Please pull the m68knommu changes for v5.8.
Regards
Greg
The following changes since commit 9cb1fd0efd195590b828b9b865421ad345a4a145:
Linux 5.7-rc7 (2020-05-24 15:32:54 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git
tags/m68knommu-for-v5.8
for you to fetch changes up to 9e2b6ed41f8f99c97b13c9d15cbef235dbd97fb6:
m68k,nommu: fix implicit cast from __user in __{get,put}_user_asm()
(2020-05-30 10:55:54 +1000)
m68knommu: collection of fixes for v5.8
Fixes include:
. casting clean up in the user access macros
. memory leak on error case fix for PCI probing
. update of a defconfig.
Bin Meng (1):
m68k: Drop CONFIG_MTD_M25P80 in stmark2_defconfig
Christophe JAILLET (1):
m68k/PCI: Fix a memory leak in an error handling path
Luc Van Oostenryck (2):
m68k,nommu: add missing __user in uaccess' __ptr() macro
m68k,nommu: fix implicit cast from __user in __{get,put}_user_asm()
arch/m68k/coldfire/pci.c| 4 +++-
arch/m68k/configs/stmark2_defconfig | 1 -
arch/m68k/include/asm/uaccess_no.h | 6 +++---
3 files changed, 6 insertions(+), 5 deletions(-)
[PATCH v4] scsi: ufs: Fix imprecise load calculation in devfreq window
The UFS load calculation is based on "total_time" and "busy_time" in a
devfreq window. However, the source of time is different for both
parameters: "busy_time" is assigned from "jiffies" thus has different
accuracy from "total_time" which is assigned from ktime_get().
Besides, the time of window boundary is not exactly the same as
the starting busy time in this window if UFS is actually busy
in the beginning of the window. A similar accuracy error may also
happen for the end of busy time in current window.
To guarantee the precision of load calculation, we need to
1. Align time accuracy of both devfreq_dev_status.total_time and
devfreq_dev_status.busy_time. For example, use "ktime_get()"
directly.
2. Align below timelines,
- The beginning time of devfreq windows
- The beginning of busy time in a new window
- The end of busy time in the current window
Fixes: a3cd5ec55f6c ("scsi: ufs: add load based scaling of UFS gear")
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufshcd.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index ad4fc829cbb2..bf5aaf334ccd 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1314,6 +1314,7 @@ static int ufshcd_devfreq_get_dev_status(struct device
*dev,
unsigned long flags;
struct list_head *clk_list = >clk_list_head;
struct ufs_clk_info *clki;
+ ktime_t curr_t;
if (!ufshcd_is_clkscaling_supported(hba))
return -EINVAL;
@@ -1321,6 +1322,7 @@ static int ufshcd_devfreq_get_dev_status(struct device
*dev,
memset(stat, 0, sizeof(*stat));
spin_lock_irqsave(hba->host->host_lock, flags);
+ curr_t = ktime_get();
if (!scaling->window_start_t)
goto start_window;
@@ -1332,18 +1334,17 @@ static int ufshcd_devfreq_get_dev_status(struct device
*dev,
*/
stat->current_frequency = clki->curr_freq;
if (scaling->is_busy_started)
- scaling->tot_busy_t += ktime_to_us(ktime_sub(ktime_get(),
+ scaling->tot_busy_t += ktime_to_us(ktime_sub(curr_t,
scaling->busy_start_t));
- stat->total_time = jiffies_to_usecs((long)jiffies -
- (long)scaling->window_start_t);
+ stat->total_time = ktime_to_us(curr_t) - scaling->window_start_t;
stat->busy_time = scaling->tot_busy_t;
start_window:
- scaling->window_start_t = jiffies;
+ scaling->window_start_t = ktime_to_us(curr_t);
scaling->tot_busy_t = 0;
if (hba->outstanding_reqs) {
- scaling->busy_start_t = ktime_get();
+ scaling->busy_start_t = curr_t;
scaling->is_busy_started = true;
} else {
scaling->busy_start_t = 0;
@@ -1877,6 +1878,7 @@ static void ufshcd_exit_clk_gating(struct ufs_hba *hba)
static void ufshcd_clk_scaling_start_busy(struct ufs_hba *hba)
{
bool queue_resume_work = false;
+ ktime_t curr_t = ktime_get();
if (!ufshcd_is_clkscaling_supported(hba))
return;
@@ -1892,13 +1894,13 @@ static void ufshcd_clk_scaling_start_busy(struct
ufs_hba *hba)
>clk_scaling.resume_work);
if (!hba->clk_scaling.window_start_t) {
- hba->clk_scaling.window_start_t = jiffies;
+ hba->clk_scaling.window_start_t = ktime_to_us(curr_t);
hba->clk_scaling.tot_busy_t = 0;
hba->clk_scaling.is_busy_started = false;
}
if (!hba->clk_scaling.is_busy_started) {
- hba->clk_scaling.busy_start_t = ktime_get();
+ hba->clk_scaling.busy_start_t = curr_t;
hba->clk_scaling.is_busy_started = true;
}
}
--
2.18.0
Re: [RFC PATCH] fix use after free in xlog_wait()
On Thu, Jun 11, 2020 at 11:01:38AM +0800, yukuai (C) wrote: > On 2020/6/11 10:28, Dave Chinner wrote > > Actually, it's a lot simpler: > > > > thread1 thread2 > > > > __xfs_trans_commit > > xfs_log_commit_cil > >xlog_wait > > schedule > > xlog_cil_push_work > > wake_up_all > > > > xlog_cil_committed > > kmem_free > > > > remove_wait_queue > > spin_lock_irqsave --> UAF > > > > It's ture in this case, however, I got another result when I > tried to reporduce it, which seems 'ctx' can be freed in a > different path: Yup, it's effectively the same thing because of the nature of the IO failures (generated at submit time) and scheduler behaviour of workqueues. THis means the IO completion that processes the error is is queued to a workqueue on the same CPU. When thread 2 finishes running (it hasn't seen an error yet) the completion work will get get scheduled ahead of thread1 (cpu bound kernel task vs unbound user task). The completion work then runs the shutdown because it saw a log IO error and because it's the commit record bio it runs the journal checkpoint completion to abort all the items attached to it and free the CIL context. Then thread 1 runs again. The only difference between the two cases is which IO of the CIL commit the request was failed on Cheers, Dave. -- Dave Chinner da...@fromorbit.com
[PATCH v1 RFC 1/2] spi: introduce fallback to pio
Add SPI_CONTROLLER_FALLBACK to fallback to pio mode in case dma transfer
failed.
If spi client driver want to enable this feature please set master->flags
with SPI_MASTER_FALLBACK and add master->fallback checking in its can_dma()
as spi-imx.c
Signed-off-by: Robin Gong
---
drivers/spi/spi.c | 11 +++
include/linux/spi/spi.h | 4
2 files changed, 15 insertions(+)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 8158e28..3bf860c 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -982,6 +982,8 @@ static int __spi_unmap_msg(struct spi_controller *ctlr,
struct spi_message *msg)
spi_unmap_buf(ctlr, tx_dev, >tx_sg, DMA_TO_DEVICE);
}
+ ctlr->cur_msg_mapped = false;
+
return 0;
}
#else /* !CONFIG_HAS_DMA */
@@ -1234,8 +1236,16 @@ static int spi_transfer_one_message(struct
spi_controller *ctlr,
if (xfer->tx_buf || xfer->rx_buf) {
reinit_completion(>xfer_completion);
+fallback_pio:
ret = ctlr->transfer_one(ctlr, msg->spi, xfer);
if (ret < 0) {
+ if (ctlr->cur_msg_mapped &&
+ (ctlr->flags & SPI_CONTROLLER_FALLBACK)) {
+ __spi_unmap_msg(ctlr, msg);
+ ctlr->fallback = true;
+ goto fallback_pio;
+ }
+
SPI_STATISTICS_INCREMENT_FIELD(statm,
errors);
SPI_STATISTICS_INCREMENT_FIELD(stats,
@@ -1693,6 +1703,7 @@ void spi_finalize_current_message(struct spi_controller
*ctlr)
spin_lock_irqsave(>queue_lock, flags);
ctlr->cur_msg = NULL;
ctlr->cur_msg_prepared = false;
+ ctlr->fallback = false;
kthread_queue_work(>kworker, >pump_messages);
spin_unlock_irqrestore(>queue_lock, flags);
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index aac57b5..95291fe4 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -506,6 +506,8 @@ struct spi_controller {
#define SPI_CONTROLLER_MUST_TX BIT(4) /* requires tx */
#define SPI_MASTER_GPIO_SS BIT(5) /* GPIO CS must select slave */
+/* fallback to PIO if DMA failed */
+#define SPI_CONTROLLER_FALLBACKBIT(6)
/* flag indicating this is an SPI slave controller */
boolslave;
@@ -602,6 +604,7 @@ struct spi_controller {
boolauto_runtime_pm;
boolcur_msg_prepared;
boolcur_msg_mapped;
+ boolfallback;
struct completion xfer_completion;
size_t max_dma_len;
@@ -1517,6 +1520,7 @@ of_find_spi_device_by_node(struct device_node *node)
#define SPI_MASTER_NO_TX SPI_CONTROLLER_NO_TX
#define SPI_MASTER_MUST_RX SPI_CONTROLLER_MUST_RX
#define SPI_MASTER_MUST_TX SPI_CONTROLLER_MUST_TX
+#define SPI_MASTER_FALLBACKSPI_CONTROLLER_FALLBACK
#define spi_master_get_devdata(_ctlr) spi_controller_get_devdata(_ctlr)
#define spi_master_set_devdata(_ctlr, _data) \
--
2.7.4
[PATCH v1 RFC 2/2] spi: spi-imx: add fallback feature
Add fallback pio feature for dma transfer failed. Since another whole
pio transfer including setup_transfer will be issued by spi core, no
need to restore jobs like commit bcd8e7761ec9 ("spi: imx: fallback to PIO
if dma setup failure").
Signed-off-by: Robin Gong
---
drivers/spi/spi-imx.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index b7a85e3..afd31d7 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -224,7 +224,7 @@ static bool spi_imx_can_dma(struct spi_master *master,
struct spi_device *spi,
{
struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
- if (!use_dma)
+ if (!use_dma || master->fallback)
return false;
if (!master->dma_rx)
@@ -1302,7 +1302,8 @@ static int spi_imx_sdma_init(struct device *dev, struct
spi_imx_data *spi_imx,
master->can_dma = spi_imx_can_dma;
master->max_dma_len = MAX_SDMA_BD_BYTES;
spi_imx->bitbang.master->flags = SPI_MASTER_MUST_RX |
-SPI_MASTER_MUST_TX;
+SPI_MASTER_MUST_TX |
+SPI_MASTER_FALLBACK;
return 0;
err:
@@ -1507,7 +1508,6 @@ static int spi_imx_transfer(struct spi_device *spi,
struct spi_transfer *transfer)
{
struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
- int ret;
/* flush rxfifo before transfer */
while (spi_imx->devtype_data->rx_available(spi_imx))
@@ -1516,21 +1516,8 @@ static int spi_imx_transfer(struct spi_device *spi,
if (spi_imx->slave_mode)
return spi_imx_pio_transfer_slave(spi, transfer);
- /*
-* fallback PIO mode if dma setup error happen, for example sdma
-* firmware may not be updated as ERR009165 required.
-*/
- if (spi_imx->usedma) {
- ret = spi_imx_dma_transfer(spi_imx, transfer);
- if (ret != -EINVAL)
- return ret;
-
- spi_imx->devtype_data->disable_dma(spi_imx);
-
- spi_imx->usedma = false;
- spi_imx->dynamic_burst = spi_imx->devtype_data->dynamic_burst;
- dev_dbg(>dev, "Fallback to PIO mode\n");
- }
+ if (spi_imx->usedma)
+ return spi_imx_dma_transfer(spi_imx, transfer);
return spi_imx_pio_transfer(spi, transfer);
}
--
2.7.4
[PATCH v1 RFC 0/2] introduce fallback to pio in spi core
Introudce fallback pio way at spi core level so that the tx/rx buffer mapped by spi core for dma could be unmap and fallback pio again. Hence no need the below patch where 'dma_sync_sg_for_devic' to sync fresh data back into 'device' memory and sync to 'cpu' again in spi core. https://www.spinics.net/lists/arm-kernel/msg812236.html If you want to use this fallback feature, please set 'master->flags' with SPI_MASTER_FALLBACK and add 'master->fallback' checking in your can_dma() to ensure it can fallback to pio. Robin Gong (2): spi: introduce fallback to pio spi: spi-imx: add fallback feature drivers/spi/spi-imx.c | 23 +-- drivers/spi/spi.c | 11 +++ include/linux/spi/spi.h | 4 3 files changed, 20 insertions(+), 18 deletions(-) -- 2.7.4
drivers/crypto/marvell/octeontx/otx_cptpf_ucode.c:881:45: sparse: sparse: incorrect type in assignment (different base types)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: b29482fde649c72441d5478a4ea2c52c56d97a5e commit: 6482023b9d3350bf1b756ef36e1ea1a1c871879c crypto: marvell - enable OcteonTX cpt options for build date: 3 months ago config: s390-randconfig-s032-20200611 (attached as .config) compiler: s390-linux-gcc (GCC) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.1-250-g42323db3-dirty git checkout 6482023b9d3350bf1b756ef36e1ea1a1c871879c # save the attached .config to linux build tree make W=1 C=1 ARCH=s390 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) drivers/crypto/marvell/octeontx/otx_cptpf_ucode.c:306:22: sparse: sparse: cast to restricted __be32 >> drivers/crypto/marvell/octeontx/otx_cptpf_ucode.c:881:45: sparse: sparse: >> incorrect type in assignment (different base types) @@ expected unsigned >> long long [usertype] @@ got restricted __be64 [usertype] @@ >> drivers/crypto/marvell/octeontx/otx_cptpf_ucode.c:881:45: sparse: >> expected unsigned long long [usertype] >> drivers/crypto/marvell/octeontx/otx_cptpf_ucode.c:881:45: sparse: got >> restricted __be64 [usertype] >> drivers/crypto/marvell/octeontx/otx_cptpf_ucode.c:885:45: sparse: sparse: >> incorrect type in assignment (different base types) @@ expected unsigned >> short [usertype] @@ got restricted __be16 [usertype] @@ >> drivers/crypto/marvell/octeontx/otx_cptpf_ucode.c:885:45: sparse: >> expected unsigned short [usertype] >> drivers/crypto/marvell/octeontx/otx_cptpf_ucode.c:885:45: sparse: got >> restricted __be16 [usertype] drivers/crypto/marvell/octeontx/otx_cptpf_ucode.c:905:23: sparse: sparse: cast to restricted __be32 include/asm-generic/io.h:236:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned long long [usertype] val @@ got restricted __le64 [usertype] @@ include/asm-generic/io.h:236:22: sparse: expected unsigned long long [usertype] val include/asm-generic/io.h:236:22: sparse: got restricted __le64 [usertype] include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:236:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned long long [usertype] val @@ got restricted __le64 [usertype] @@ include/asm-generic/io.h:236:22: sparse: expected unsigned long long [usertype] val include/asm-generic/io.h:236:22: sparse: got restricted __le64 [usertype] include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64 include/asm-generic/io.h:193:15: sparse: sparse: cast to restricted __le64
Re: INFO: task hung in corrupted (2)
On Thu, Jun 04, 2020 at 01:41:07PM +0200, Jiri Kosina wrote:
> On Tue, 2 Jun 2020, Andrey Konovalov wrote:
>
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:b0c3ba31 Merge tag 'fsnotify_for_v5.7-rc8' of
> > > git://git.ke..
> > > git tree: upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=14089eee10
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=ce116858301bc2ea
> > > dashboard link:
> > > https://syzkaller.appspot.com/bug?extid=6921abfb75d6fc79c0eb
> > > compiler: clang version 10.0.0
> > > (https://github.com/llvm/llvm-project/
> > > c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14947d2610
> > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=172726d210
> > >
> > > The bug was bisected 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=119e470210
> > > final crash:
> > > https://syzkaller.appspot.com/x/report.txt?x=139e470210
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=159e470210
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+6921abfb75d6fc79c...@syzkaller.appspotmail.com
> > > Fixes: f2c2e717642c ("usb: gadget: add raw-gadget interface")
> > >
> > > INFO: task syz-executor610:7072 blocked for more than 143 seconds.
> > > Not tainted 5.7.0-rc7-syzkaller #0
> > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > > syz-executor610 D24336 7072 7071 0x80004002
> > > Call Trace:
> > > context_switch kernel/sched/core.c:3367 [inline]
> > > __schedule+0x805/0xc90 kernel/sched/core.c:4083
> > >
> > > Showing all locks held in the system:
> > > 1 lock held by khungtaskd/1134:
> > > #0: 892e85d0 (rcu_read_lock){}-{1:2}, at:
> > > rcu_lock_acquire+0x0/0x30 net/mptcp/pm_netlink.c:860
> > > 1 lock held by in:imklog/6715:
> > > #0: 8880a441e6b0 (>f_pos_lock){+.+.}-{3:3}, at:
> > > __fdget_pos+0x25d/0x2f0 fs/file.c:826
> > > 6 locks held by kworker/1:0/7064:
> > > 1 lock held by syz-executor610/7072:
> > > #0: 892eab20 (rcu_state.exp_mutex){+.+.}-{3:3}, at:
> > > exp_funnel_lock kernel/rcu/tree_exp.h:290 [inline]
> > > #0: 892eab20 (rcu_state.exp_mutex){+.+.}-{3:3}, at:
> > > synchronize_rcu_expedited+0x1bd/0x5b0 kernel/rcu/tree_exp.h:856
> > > 4 locks held by systemd-udevd/7099:
> > > #0: 8880a7fdcc70 (>lock){+.+.}-{3:3}, at: seq_read+0x60/0xce0
> > > fs/seq_file.c:153
> > > #1: 888096486888 (>mutex){+.+.}-{3:3}, at:
> > > kernfs_seq_start+0x50/0x3b0 fs/kernfs/file.c:111
> > > #2: 88809fc0d660 (kn->count#78){.+.+}-{0:0}, at:
> > > kernfs_seq_start+0x6f/0x3b0 fs/kernfs/file.c:112
> > > #3: 8880a1df7218 (>mutex){}-{3:3}, at:
> > > device_lock_interruptible include/linux/device.h:773 [inline]
> > > #3: 8880a1df7218 (>mutex){}-{3:3}, at:
> > > serial_show+0x22/0xa0 drivers/usb/core/sysfs.c:142
> > >
> > > =
> > >
> > > NMI backtrace for cpu 0
> > > CPU: 0 PID: 1134 Comm: khungtaskd Not tainted 5.7.0-rc7-syzkaller #0
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > Google 01/01/2011
> > > Call Trace:
> > > __dump_stack lib/dump_stack.c:77 [inline]
> > > dump_stack+0x1e9/0x30e lib/dump_stack.c:118
> > > nmi_cpu_backtrace+0x9f/0x180 lib/nmi_backtrace.c:101
> > > nmi_trigger_cpumask_backtrace+0x16a/0x280 lib/nmi_backtrace.c:62
> > > check_hung_uninterruptible_tasks kernel/hung_task.c:205 [inline]
> > > watchdog+0xd2a/0xd40 kernel/hung_task.c:289
> > > kthread+0x353/0x380 kernel/kthread.c:268
> > > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:351
> > > Sending NMI from CPU 0 to CPUs 1:
> > > NMI backtrace for cpu 1
> > > CPU: 1 PID: 7064 Comm: kworker/1:0 Not tainted 5.7.0-rc7-syzkaller #0
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > Google 01/01/2011
> > > Workqueue: usb_hub_wq hub_event
> > > RIP: 0010:__sanitizer_cov_trace_const_cmp4+0x0/0x90 kernel/kcov.c:275
> > > Code: 4c f2 08 48 c1 e0 03 48 83 c8 18 49 89 14 02 4d 89 44 f2 18 49 ff
> > > c1 4d 89 0a c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 <4c> 8b 04 24
> > > 65 48 8b 04 25 40 1e 02 00 65 8b 0d 78 96 8e 7e f7 c1
> > > RSP: 0018:c90001676cf0 EFLAGS: 0246
> > > RAX: RBX: RCX: 88809fb9e240
> > > RDX: RSI: RDI:
> > > RBP: 888092d24a04 R08: 86034f3b R09: c900016790cc
> > > R10: 0004 R11: R12: 888092d24a00
> > > R13: R14: dc00 R15: 888092d24a00
INFO: task hung in do_truncate (2)
Hello, syzbot found the following crash on: HEAD commit:7ae77150 Merge tag 'powerpc-5.8-1' of git://git.kernel.org.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=150f296110 kernel config: https://syzkaller.appspot.com/x/.config?x=d195fe572fb15312 dashboard link: https://syzkaller.appspot.com/bug?extid=18b2ab4c697021ee8369 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15cec29610 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=153a741e10 Bisection is inconclusive: the bug happens on the oldest tested release. bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=e2c110 final crash:https://syzkaller.appspot.com/x/report.txt?x=1311e2c110 console output: https://syzkaller.appspot.com/x/log.txt?x=1511e2c110 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+18b2ab4c697021ee8...@syzkaller.appspotmail.com INFO: task syz-executor283:6874 blocked for more than 143 seconds. Not tainted 5.7.0-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. syz-executor283 D28400 6874 6804 0x4004 Call Trace: context_switch kernel/sched/core.c:3430 [inline] __schedule+0x8f3/0x1fc0 kernel/sched/core.c:4156 schedule+0xd0/0x2a0 kernel/sched/core.c:4231 rwsem_down_write_slowpath+0x706/0xf90 kernel/locking/rwsem.c:1235 __down_write kernel/locking/rwsem.c:1389 [inline] down_write+0x137/0x150 kernel/locking/rwsem.c:1532 inode_lock include/linux/fs.h:799 [inline] do_truncate+0x125/0x1f0 fs/open.c:62 handle_truncate fs/namei.c:2887 [inline] do_open fs/namei.c:3233 [inline] path_openat+0x1f28/0x27d0 fs/namei.c:3346 do_filp_open+0x192/0x260 fs/namei.c:3373 do_sys_openat2+0x585/0x7d0 fs/open.c:1179 do_sys_open+0xc3/0x140 fs/open.c:1195 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 RIP: 0033:0x4468f9 Code: Bad RIP value. RSP: 002b:7f3df9c40db8 EFLAGS: 0246 ORIG_RAX: 0101 RAX: ffda RBX: 006dbc28 RCX: 004468f9 RDX: 275a RSI: 21c0 RDI: ff9c RBP: 006dbc20 R08: R09: R10: R11: 0246 R12: 006dbc2c R13: 7ffe3e295ecf R14: 7f3df9c419c0 R15: INFO: task syz-executor283:6877 blocked for more than 143 seconds. Not tainted 5.7.0-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. syz-executor283 D28400 6877 6805 0x0004 Call Trace: context_switch kernel/sched/core.c:3430 [inline] __schedule+0x8f3/0x1fc0 kernel/sched/core.c:4156 schedule+0xd0/0x2a0 kernel/sched/core.c:4231 rwsem_down_write_slowpath+0x706/0xf90 kernel/locking/rwsem.c:1235 __down_write kernel/locking/rwsem.c:1389 [inline] down_write+0x137/0x150 kernel/locking/rwsem.c:1532 inode_lock include/linux/fs.h:799 [inline] process_measurement+0x15ec/0x1750 security/integrity/ima/ima_main.c:228 ima_file_check+0xb9/0x100 security/integrity/ima/ima_main.c:440 do_open fs/namei.c:3231 [inline] path_openat+0x1997/0x27d0 fs/namei.c:3346 do_filp_open+0x192/0x260 fs/namei.c:3373 do_sys_openat2+0x585/0x7d0 fs/open.c:1179 do_sys_open+0xc3/0x140 fs/open.c:1195 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 RIP: 0033:0x4468f9 Code: Bad RIP value. RSP: 002b:7f3df9c40db8 EFLAGS: 0246 ORIG_RAX: 0101 RAX: ffda RBX: 006dbc28 RCX: 004468f9 RDX: 275a RSI: 21c0 RDI: ff9c RBP: 006dbc20 R08: R09: R10: R11: 0246 R12: 006dbc2c R13: 7ffe3e295ecf R14: 7f3df9c419c0 R15: INFO: task syz-executor283:6880 blocked for more than 144 seconds. Not tainted 5.7.0-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. syz-executor283 D28400 6880 6803 0x0004 Call Trace: context_switch kernel/sched/core.c:3430 [inline] __schedule+0x8f3/0x1fc0 kernel/sched/core.c:4156 schedule+0xd0/0x2a0 kernel/sched/core.c:4231 rwsem_down_write_slowpath+0x706/0xf90 kernel/locking/rwsem.c:1235 __down_write kernel/locking/rwsem.c:1389 [inline] down_write+0x137/0x150 kernel/locking/rwsem.c:1532 inode_lock include/linux/fs.h:799 [inline] process_measurement+0x15ec/0x1750 security/integrity/ima/ima_main.c:228 ima_file_check+0xb9/0x100 security/integrity/ima/ima_main.c:440 do_open fs/namei.c:3231 [inline] path_openat+0x1997/0x27d0 fs/namei.c:3346 do_filp_open+0x192/0x260 fs/namei.c:3373 do_sys_openat2+0x585/0x7d0 fs/open.c:1179 do_sys_open+0xc3/0x140 fs/open.c:1195 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 RIP: 0033:0x4468f9 Code: Bad RIP value. RSP:
include/asm-generic/qspinlock.h:94:9: sparse: sparse: context imbalance in 'do_sched_cfs_period_timer' - unexpected unlock
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: b29482fde649c72441d5478a4ea2c52c56d97a5e commit: ab93a4bc955b3980c699430bc0b633f0d8b607be sched/fair: Remove distribute_running from CFS bandwidth date: 6 weeks ago config: arm64-randconfig-s032-20200611 (attached as .config) compiler: aarch64-linux-gcc (GCC) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.1-250-g42323db3-dirty git checkout ab93a4bc955b3980c699430bc0b633f0d8b607be # save the attached .config to linux build tree make W=1 C=1 ARCH=arm64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) kernel/sched/fair.c:882:34: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct sched_entity *se @@ got struct sched_entity [noderef] * @@ kernel/sched/fair.c:882:34: sparse: expected struct sched_entity *se kernel/sched/fair.c:882:34: sparse: got struct sched_entity [noderef] * kernel/sched/fair.c:4851:22: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/fair.c:4851:22: sparse:struct task_struct [noderef] * kernel/sched/fair.c:4851:22: sparse:struct task_struct * kernel/sched/fair.c:6533:20: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] sd @@ got struct sched_domain [noderef] *parent @@ kernel/sched/fair.c:6533:20: sparse: expected struct sched_domain *[assigned] sd kernel/sched/fair.c:6533:20: sparse: got struct sched_domain [noderef] *parent kernel/sched/fair.c:6652:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] tmp @@ got struct sched_domain [noderef] *parent @@ kernel/sched/fair.c:6652:9: sparse: expected struct sched_domain *[assigned] tmp kernel/sched/fair.c:6652:9: sparse: got struct sched_domain [noderef] *parent kernel/sched/fair.c:6854:38: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct task_struct *curr @@ got struct task_struct [noderef] *curr @@ kernel/sched/fair.c:6854:38: sparse: expected struct task_struct *curr kernel/sched/fair.c:6854:38: sparse: got struct task_struct [noderef] *curr kernel/sched/fair.c:7105:38: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct task_struct *curr @@ got struct task_struct [noderef] *curr @@ kernel/sched/fair.c:7105:38: sparse: expected struct task_struct *curr kernel/sched/fair.c:7105:38: sparse: got struct task_struct [noderef] *curr kernel/sched/fair.c:8063:40: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct sched_domain *child @@ got struct sched_domain [noderef] *child @@ kernel/sched/fair.c:8063:40: sparse: expected struct sched_domain *child kernel/sched/fair.c:8063:40: sparse: got struct sched_domain [noderef] *child kernel/sched/fair.c:8556:22: sparse: sparse: incompatible types in comparison expression (different address spaces): kernel/sched/fair.c:8556:22: sparse:struct task_struct [noderef] * kernel/sched/fair.c:8556:22: sparse:struct task_struct * kernel/sched/fair.c:9800:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] sd @@ got struct sched_domain [noderef] *parent @@ kernel/sched/fair.c:9800:9: sparse: expected struct sched_domain *[assigned] sd kernel/sched/fair.c:9800:9: sparse: got struct sched_domain [noderef] *parent kernel/sched/fair.c:9460:44: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct sched_domain *sd_parent @@ got struct sched_domain [noderef] *parent @@ kernel/sched/fair.c:9460:44: sparse: expected struct sched_domain *sd_parent kernel/sched/fair.c:9460:44: sparse: got struct sched_domain [noderef] *parent kernel/sched/fair.c:9879:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] sd @@ got struct sched_domain [noderef] *parent @@ kernel/sched/fair.c:9879:9: sparse: expected struct sched_domain *[assigned] sd kernel/sched/fair.c:9879:9: sparse: got struct sched_domain [noderef] *parent kernel/sched/fair.c:10479:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct sched_domain *[assigned] sd @@ got struct sched_domain [noderef] *parent @@ kernel/sched/fair.c:10479:9: sparse: expected struct sched_domain *[assigned] sd
Re: [PATCH v7 3/5] remoteproc: Add support for runtime PM
On Wed 10 Jun 02:40 PDT 2020, Paul Cercueil wrote:
> Hi,
>
> Le lun. 8 juin 2020 à 18:10, Suman Anna a écrit :
> > Hi Paul,
> >
> > On 6/8/20 5:46 PM, Paul Cercueil wrote:
> > > Hi Suman,
> > >
> > > > > > On 5/15/20 5:43 AM, Paul Cercueil wrote:
> > > > > > > Call pm_runtime_get_sync() before the firmware is loaded, and
> > > > > > > pm_runtime_put() after the remote processor has been stopped.
> > > > > > >
> > > > > > > Even though the remoteproc device has no PM
> > > > > > > callbacks, this allows the
> > > > > > > parent device's PM callbacks to be properly called.
> > > > > >
> > > > > > I see this patch staged now for 5.8, and the latest
> > > > > > -next branch has broken the pm-runtime autosuspend
> > > > > > feature we have in the OMAP remoteproc driver. See
> > > > > > commit 5f31b232c674 ("remoteproc/omap: Add support
> > > > > > for runtime auto-suspend/resume").
> > > > > >
> > > > > > What was the original purpose of this patch, because
> > > > > > there can be differing backends across different
> > > > > > SoCs.
> > > > >
> > > > > Did you try pm_suspend_ignore_children()? It looks like it
> > > > > was made for your use-case.
> > > >
> > > > Sorry for the delay in getting back. So, using
> > > > pm_suspend_ignore_children() does fix my current issue.
> > > >
> > > > But I still fail to see the original purpose of this patch in
> > > > the remoteproc core especially given that the core itself does
> > > > not have any callbacks. If the sole intention was to call the
> > > > parent pdev's callbacks, then I feel that state-machine is
> > > > better managed within that particular platform driver itself,
> > > > as the sequencing/device management can vary with different
> > > > platform drivers.
> > >
> > > The problem is that with Ingenic SoCs some clocks must be enabled in
> > > order to load the firmware, and the core doesn't give you an option
> > > to register a callback to be called before loading it.
> >
> > Yep, I have similar usage in one of my remoteproc drivers (see
> > keystone_remoteproc.c), and I think this all stems from the need to
> > use/support loading into a processor's internal memories. My driver does
> > leverage the pm-clks backend plugged into pm_runtime, so you won't see
> > explicit calls on the clocks.
> >
> > I guess the question is what exact PM features you are looking for with
> > the Ingenic SoC. I do see you are using pm_runtime autosuspend, and your
> > callbacks are managing the clocks, but reset is managed only in
> > start/stop.
> >
> > > The first version of my patchset added .prepare/.unprepare
> > > callbacks to the struct rproc_ops, but the feedback from the
> > > maintainers was that I should do it via runtime PM. However, it was
> > > not possible to keep it contained in the driver, since again the
> > > core doesn't provide a "prepare" callback, so no place to call
> > > pm_runtime_get_sync().
> > FWIW, the .prepare/.unprepare callbacks is actually now part of the
> > rproc core. Looks like multiple developers had a need for this, and this
> > functionality went in at the same time as your driver :). Not sure if
> > you looked up the prior patches, I leveraged the patch that Loic had
> > submitted a long-time ago, and a revised version of it is now part of
> > 5.8-rc1.
>
> WTF maintainers, you refuse my patchset for adding a .prepare/.unprepare,
> ask me to do it via runtime PM, then merge another patchset that adds these
> callback. At least be constant in your decisions.
>
Sorry, I missed this when applying the two patches, but you're of course
right.
> Anyway, now we have two methods added to linux-next for doing the exact same
> thing. What should we do about it?
>
I like the pm_runtime approach and as it was Arnaud that asked you to
change it, perhaps he and Loic can agree on updating the ST driver so we
can drop the prepare/unprepare ops again?
Regards,
Bjorn
Re: [PATCH v3 1/4] fs, net: Standardize on file_receive helper to move fds across processes
On Wed, Jun 10, 2020 at 07:59:55PM -0700, Kees Cook wrote:
>
> Yeah, that seems reasonable. Here's the diff for that part:
>
> diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
> index 7b6028b399d8..98bf19b4e086 100644
> --- a/include/uapi/linux/seccomp.h
> +++ b/include/uapi/linux/seccomp.h
> @@ -118,7 +118,6 @@ struct seccomp_notif_resp {
>
> /**
> * struct seccomp_notif_addfd
> - * @size: The size of the seccomp_notif_addfd datastructure
> * @id: The ID of the seccomp notification
> * @flags: SECCOMP_ADDFD_FLAG_*
> * @srcfd: The local fd number
> @@ -126,7 +125,6 @@ struct seccomp_notif_resp {
> * @newfd_flags: The O_* flags the remote FD should have applied
> */
> struct seccomp_notif_addfd {
> - __u64 size;
> __u64 id;
> __u32 flags;
> __u32 srcfd;
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 3c913f3b8451..00cbdad6c480 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -1297,14 +1297,9 @@ static long seccomp_notify_addfd(struct seccomp_filter
> *filter,
> struct seccomp_notif_addfd addfd;
> struct seccomp_knotif *knotif;
> struct seccomp_kaddfd kaddfd;
> - u64 size;
> int ret;
>
> - ret = get_user(size, >size);
> - if (ret)
> - return ret;
> -
> - ret = copy_struct_from_user(, sizeof(addfd), uaddfd, size);
> + ret = copy_from_user(, uaddfd, sizeof(addfd));
> if (ret)
> return ret;
>
>
Looks good to me. If we ever change the size of this struct, we can do the work
then to copy_struct_from_user.
> >
> >
> > +#define SECCOMP_IOCTL_NOTIF_ADDFD SECCOMP_IOR(3, \
> > + struct seccomp_notif_addfd)
> >
> > Lastly, what I believe to be a small mistake, it should be SECCOMP_IOW,
> > based on
> > the documentation in ioctl.h -- "_IOW means userland is writing and kernel
> > is
> > reading."
>
> Oh. Yeah; good catch. Uhm, that means SECCOMP_IOCTL_NOTIF_ID_VALID
> is wrong too, yes? Tycho, Christian, how disruptive would this be to
> fix? (Perhaps support both and deprecate the IOR version at some point
> in the future?)
I think at a minimum we should change the uapi, and accept both (for now).
Maybe
a pr_warn_once telling people not to use the old one.
I can do the patch, if you want.
>
> Diff for just addfd's change:
>
> diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
> index 7b6028b399d8..98bf19b4e086 100644
> --- a/include/uapi/linux/seccomp.h
> +++ b/include/uapi/linux/seccomp.h
> @@ -146,7 +144,7 @@ struct seccomp_notif_addfd {
> struct seccomp_notif_resp)
> #define SECCOMP_IOCTL_NOTIF_ID_VALID SECCOMP_IOR(2, __u64)
> /* On success, the return value is the remote process's added fd number */
> -#define SECCOMP_IOCTL_NOTIF_ADDFDSECCOMP_IOR(3, \
> +#define SECCOMP_IOCTL_NOTIF_ADDFDSECCOMP_IOW(3, \
> struct seccomp_notif_addfd)
>
> #endif /* _UAPI_LINUX_SECCOMP_H */
>
> --
> Kees Cook
Looks good. Thank you.
Re: [PATCH V2 1/2] mtd: rawnand: qcom: remove write to unavailable register
Hi Miquel, On 6/9/2020 7:32 PM, Miquel Raynal wrote: Hi Sivaprakash, Sivaprakash Murugesan wrote on Tue, 9 Jun 2020 16:40:55 +0530: SFLASHC_BURST_CFG register is not available on all ipq nand platforms, it is available only on ipq8064 devices and the nand controller works without configuring these registers in this platform, so register write to this can be removed. Maybe it works because the bootloader is setting the register itself. What if you use a different bootloader, or the same bootloader without NAND support? I don't think this is a proper fix, you should instead have a different compatible if the IP is not the same and depending on this compatible do the write, or not. I understand your point, will fix this in next patch. Thanks, Siva Thanks, Miquèl
[PATCH v2][RFC] kdump: append kernel build-id string to VMCOREINFO
Make kernel GNU build-id available in VMCOREINFO. Having
build-id in VMCOREINFO facilitates presenting appropriate kernel
namelist image with debug information file to kernel crash dump
analysis tools. Currently VMCOREINFO lacks uniquely identifiable
key for crash analysis automation.
Regarding if this patch is necessary or matching of linux_banner
and OSRELEASE in VMCOREINFO employed by crash(8) meets the
need -- IMO, build-id approach more foolproof, in most instances it
is a cryptographic hash generated using internal code/ELF bits unlike
kernel version string upon which linux_banner is based that is
external to the code. I feel each is intended for a different purpose.
Also OSRELEASE is not suitable when two different kernel builds
from same version with different features enabled.
Currently for most linux (and non-linux) systems build-id can be
extracted using standard methods for file types such as user mode crash
dumps, shared libraries, loadable kernel modules etc., This is an
exception for linux kernel dump. Having build-id in VMCOREINFO brings
some uniformity for automation tools.
Signed-off-by: Vijay Balakrishna
---
Changes since v2:
-
- v1 was sent out as a single patch which can be seen here:
http://lists.infradead.org/pipermail/kexec/2020-June/025202.html
- moved justification to commit commit log
- renamed 'g_build_id' to 'note_sec'
- fixed format specifier in pr_warn() from '%lu' to '%u' (failed to
catch warning in v1)
include/linux/crash_core.h | 6 +
kernel/crash_core.c| 50 ++
2 files changed, 56 insertions(+)
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index 525510a9f965..6594dbc34a37 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -38,6 +38,8 @@ phys_addr_t paddr_vmcoreinfo_note(void);
#define VMCOREINFO_OSRELEASE(value) \
vmcoreinfo_append_str("OSRELEASE=%s\n", value)
+#define VMCOREINFO_BUILD_ID(value) \
+ vmcoreinfo_append_str("BUILD-ID=%s\n", value)
#define VMCOREINFO_PAGESIZE(value) \
vmcoreinfo_append_str("PAGESIZE=%ld\n", value)
#define VMCOREINFO_SYMBOL(name) \
@@ -64,6 +66,10 @@ extern unsigned char *vmcoreinfo_data;
extern size_t vmcoreinfo_size;
extern u32 *vmcoreinfo_note;
+/* raw contents of kernel .notes section */
+extern const void __start_notes __weak;
+extern const void __stop_notes __weak;
+
Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
void *data, size_t data_len);
void final_note(Elf_Word *buf);
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 9f1557b98468..64ac359cd17e 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -11,6 +11,8 @@
#include
#include
+#include
+
/* vmcoreinfo stuff */
unsigned char *vmcoreinfo_data;
size_t vmcoreinfo_size;
@@ -376,6 +378,53 @@ phys_addr_t __weak paddr_vmcoreinfo_note(void)
}
EXPORT_SYMBOL(paddr_vmcoreinfo_note);
+#define NOTES_SIZE (&__stop_notes - &__start_notes)
+#define BUILD_ID_MAX SHA1_DIGEST_SIZE
+#define NT_GNU_BUILD_ID 3
+
+struct elf_note_section {
+ struct elf_note n_hdr;
+ u8 n_data[];
+};
+
+/*
+ * Add build ID from .notes section as generated by the GNU ld(1)
+ * or LLVM lld(1) --build-id option.
+ */
+static void add_build_id_vmcoreinfo(void)
+{
+ char build_id[BUILD_ID_MAX * 2 + 1];
+ int n_remain = NOTES_SIZE;
+
+ while (n_remain >= sizeof(struct elf_note)) {
+ const struct elf_note_section *note_sec =
+ &__start_notes + NOTES_SIZE - n_remain;
+ const u32 n_namesz = note_sec->n_hdr.n_namesz;
+
+ if (note_sec->n_hdr.n_type == NT_GNU_BUILD_ID &&
+ n_namesz != 0 &&
+ !strcmp((char *)_sec->n_data[0], "GNU")) {
+ if (note_sec->n_hdr.n_descsz <= BUILD_ID_MAX) {
+ const u32 n_descsz = note_sec->n_hdr.n_descsz;
+ const u8 *s = _sec->n_data[n_namesz];
+
+ s = PTR_ALIGN(s, 4);
+ bin2hex(build_id, s, n_descsz);
+ build_id[2 * n_descsz] = '\0';
+ VMCOREINFO_BUILD_ID(build_id);
+ return;
+ }
+ pr_warn("Build ID is too large to include in
vmcoreinfo: %u > %u\n",
+ note_sec->n_hdr.n_descsz,
+ BUILD_ID_MAX);
+ return;
+ }
+ n_remain -= sizeof(struct elf_note) +
+ ALIGN(note_sec->n_hdr.n_namesz, 4) +
+ ALIGN(note_sec->n_hdr.n_descsz, 4);
+ }
+}
+
static int __init crash_save_vmcoreinfo_init(void)
{
vmcoreinfo_data = (unsigned char *)get_zeroed_page(GFP_KERNEL);
@@ -394,6 +443,7 @@ static int __init
Re: [PATCH V2 2/2] mtd: rawnand: qcom: set BAM mode only if not set already
Hi Miquel,
Thanks for the review.
On 6/9/2020 7:33 PM, Miquel Raynal wrote:
Hi Sivaprakash,
Sivaprakash Murugesan wrote on Tue, 9 Jun
2020 16:40:56 +0530:
BAM mode is set by writing BAM_MODE_EN bit on NAND_CTRL register.
NAND_CTRL is an operational register and in BAM mode operational
registers are read only.
So, before writing into NAND_CTRL register check if BAM mode is already
enabled by bootloader, and set BAM mode only if it is not set already.
Signed-off-by: Sivaprakash Murugesan
---
drivers/mtd/nand/raw/qcom_nandc.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/qcom_nandc.c
b/drivers/mtd/nand/raw/qcom_nandc.c
index e0afa2c..7740059 100644
--- a/drivers/mtd/nand/raw/qcom_nandc.c
+++ b/drivers/mtd/nand/raw/qcom_nandc.c
@@ -2779,7 +2779,14 @@ static int qcom_nandc_setup(struct qcom_nand_controller
*nandc)
/* enable ADM or BAM DMA */
if (nandc->props->is_bam) {
nand_ctrl = nandc_read(nandc, NAND_CTRL);
- nandc_write(nandc, NAND_CTRL, nand_ctrl | BAM_MODE_EN);
+ /* NAND_CTRL is an operational registers, and CPU
+* access to operational registers are read only
+* in BAM mode. So update the NAND_CTRL register
+* only if it is not in BAM mode. In most cases BAM
+* mode will be enabled in bootloader
+*/
+ if (!(nand_ctrl | BAM_MODE_EN))
+ nandc_write(nandc, NAND_CTRL, nand_ctrl | BAM_MODE_EN);
} else {
nandc_write(nandc, NAND_FLASH_CHIP_SELECT, DM_EN);
}
Does this currently produces an issue at runtime?
If yes, you should have a Fixes/CC: stable pair of tags.
Also, what is BAM mode? Please tell us in the commit log.
Currently this is not causing any issue on run time.
The writes to this register is silently ignored.
However, this could be an issue in future Hardware designs.
BAM is the DMA engine on QCOM IPQ platforms, sure will explain this
mode in next patchset.
Thanks,
Miquèl
Re: [PATCH v2] usb: gadget: configfs: Fix KASAN use-after-free
On Thu, 2017-09-01 at 10:25:32 -0700, Kees Cook wrote:
> Subject: Re: [PATCH v2] usb: gadget: configfs: Fix KASAN use-after-free
> To: Jim Lin
> Cc: Felipe Balbi , , LKML
> , Greg KH ,
> Steve Beattie
>
>
> On Tue, Jan 17, 2017 at 1:29 AM, Jim Lin wrote:
> > When gadget is disconnected, running sequence is like this.
> > . composite_disconnect
> > . Call trace:
> > usb_string_copy+0xd0/0x128
> > gadget_config_name_configuration_store+0x4
> > gadget_config_name_attr_store+0x40/0x50
> > configfs_write_file+0x198/0x1f4
> > vfs_write+0x100/0x220
> > SyS_write+0x58/0xa8
> > . configfs_composite_unbind
> > . configfs_composite_bind
> >
> > In configfs_composite_bind, it has
> > "cn->strings.s = cn->configuration;"
> >
> > When usb_string_copy is invoked. it would
> > allocate memory, copy input string, release previous pointed memory space,
> > and use new allocated memory.
> >
> > When gadget is connected, host sends down request to get information.
> > Call trace:
> > usb_gadget_get_string+0xec/0x168
> > lookup_string+0x64/0x98
> > composite_setup+0xa34/0x1ee8
> > android_setup+0xb4/0x140
> >
> > If gadget is disconnected and connected quickly, in the failed case,
> > cn->configuration memory has been released by usb_string_copy kfree but
> > configfs_composite_bind hasn't been run in time to assign new allocated
> > "cn->configuration" pointer to "cn->strings.s".
> >
> > When "strlen(s->s) of usb_gadget_get_string is being executed, the dangling
> > memory is accessed, "BUG: KASAN: use-after-free" error occurs.
> >
> > Signed-off-by: Jim Lin
>
> Hi! What's the current state of this patch?
Mediatek is using this bug fix in Android kernel 3.18, 4.4, 4.9, 4.14
and 4.19. Kernel code nowadays.
Since there are news that Google is planning to use Generic Kernel Image
(GKI) for future Android. Should this patch be refined and adapt into
Linux?
Dear Jim and Siqi, according to Felipe's mail before, do you have
environments to test it on a Linux environment like on PC? Maybe on some
embedded environment not using Android or Chromium OS? I don't have that
kind of environment in my office hence I just couldn't provide a help to
do the test.
> > ---
> > Changes in v2:
> > Rephrase commit description
> >
> > drivers/usb/gadget/configfs.c | 15 +++
> > 1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
> > index 78c4497..39fea62 100644
> > --- a/drivers/usb/gadget/configfs.c
> > +++ b/drivers/usb/gadget/configfs.c
> > @@ -106,6 +106,9 @@ struct gadget_config_name {
> > struct list_head list;
> > };
> >
> > +#define MAX_USB_STRING_LEN 126
> > +#define MAX_USB_STRING_WITH_NULL_LEN (MAX_USB_STRING_LEN+1)
> > +
> > static int usb_string_copy(const char *s, char **s_copy)
> > {
> > int ret;
> > @@ -115,12 +118,16 @@ static int usb_string_copy(const char *s, char
> > **s_copy)
> > if (ret > 126)
>
> This should be MAX_USB_STRING_LEN, yes?
>
> > return -EOVERFLOW;
> >
> > - str = kstrdup(s, GFP_KERNEL);
> > - if (!str)
> > - return -ENOMEM;
> > + if (copy) {
> > + str = copy;
> > + } else {
> > + str = kmalloc(MAX_USB_STRING_WITH_NULL_LEN, GFP_KERNEL);
> > + if (!str)
> > + return -ENOMEM;
> > + }
> > + strcpy(str, s);
> > if (str[ret - 1] == '\n')
> > str[ret - 1] = '\0';
> > - kfree(copy);
> > *s_copy = str;
> > return 0;
> > }
> > --
> > 2.7.4
> >
>
> -Kees
Thank you very much.
Macpaul Lin
[GIT PULL] Mailbox changes for v5.8
Hi Linus, The following changes since commit ffeb595d84811dde16a28b33d8a7cf26d51d51b3: Merge tag 'powerpc-5.7-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux (2020-05-30 12:28:44 -0700) are available in the Git repository at: git://git.linaro.org/landing-teams/working/fujitsu/integration.git tags/mailbox-v5.8 for you to fetch changes up to e9f901dc05c09c4f89183cadcb2d93177f3100cb: mailbox: qcom: Add ipq6018 apcs compatible (2020-06-10 22:43:57 -0500) - qcom : new controller driver for IPCC reorg the of_device data add support for ipq6018 platform - spreadtrum: new sprd controller driver - imx: implement suspend/resume PM support - Misc : make pcc driver struct as static fix return value in imx_mu_scu disable clock before bailout in imx probe remove duplicate error mssg in zynqmp probe fix header size in imx.scu check for null instead of is-err in zynqmp Anson Huang (3): mailbox: imx: Support runtime PM mailbox: imx: Add runtime PM callback to handle MU clocks mailbox: imx: ONLY IPC MU needs IRQF_NO_SUSPEND flag Baolin Wang (2): dt-bindings: mailbox: Add the Spreadtrum mailbox documentation mailbox: sprd: Add Spreadtrum mailbox driver Dan Carpenter (1): mailbox: imx: Fix return in imx_mu_scu_xlate() Dong Aisheng (1): mailbox: imx: Add context save/restore for suspend/resume Fabio Estevam (1): mailbox: imx: Disable the clock on devm_mbox_controller_register() failure Jason Yan (1): mailbox: pcc: make pcc_mbox_driver static Manivannan Sadhasivam (3): dt-bindings: mailbox: Add devicetree binding for Qcom IPCC mailbox: Add support for Qualcomm IPCC MAINTAINERS: Add entry for Qualcomm IPCC driver Markus Elfring (1): mailbox: ZynqMP IPI: Delete an error message in zynqmp_ipi_probe() Peng Fan (1): mailbox: imx-mailbox: fix scu msg header size check Sivaprakash Murugesan (3): dt-bindings: mailbox: Add YAML schemas for QCOM APCS global block mailbox: qcom: Add clock driver name in apcs mailbox driver data mailbox: qcom: Add ipq6018 apcs compatible Wei Yongjun (1): mailbox: zynqmp-ipi: Fix NULL vs IS_ERR() check in zynqmp_ipi_mbox_probe() .../bindings/mailbox/qcom,apcs-kpss-global.txt | 88 - .../bindings/mailbox/qcom,apcs-kpss-global.yaml| 86 + .../devicetree/bindings/mailbox/qcom-ipcc.yaml | 80 + .../devicetree/bindings/mailbox/sprd-mailbox.yaml | 60 MAINTAINERS| 8 + drivers/mailbox/Kconfig| 18 + drivers/mailbox/Makefile | 4 + drivers/mailbox/imx-mailbox.c | 117 ++- drivers/mailbox/pcc.c | 2 +- drivers/mailbox/qcom-apcs-ipc-mailbox.c| 61 +++- drivers/mailbox/qcom-ipcc.c| 286 drivers/mailbox/sprd-mailbox.c | 361 + drivers/mailbox/zynqmp-ipi-mailbox.c | 25 +- include/dt-bindings/mailbox/qcom-ipcc.h| 33 ++ 14 files changed, 1097 insertions(+), 132 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt create mode 100644 Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml create mode 100644 Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml create mode 100644 Documentation/devicetree/bindings/mailbox/sprd-mailbox.yaml create mode 100644 drivers/mailbox/qcom-ipcc.c create mode 100644 drivers/mailbox/sprd-mailbox.c create mode 100644 include/dt-bindings/mailbox/qcom-ipcc.h
[PATCH v2 2/3] iommu/uapi: Add argsz for user filled data
As IOMMU UAPI gets extended, user data size may increase. To support
backward compatibiliy, this patch introduces a size field to each UAPI
data structures. It is *always* the responsibility for the user to fill in
the correct size.
Specific scenarios for user data handling are documented in:
Documentation/userspace-api/iommu.rst
Signed-off-by: Liu Yi L
Signed-off-by: Jacob Pan
---
include/uapi/linux/iommu.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h
index e907b7091a46..303f148a5cd7 100644
--- a/include/uapi/linux/iommu.h
+++ b/include/uapi/linux/iommu.h
@@ -135,6 +135,7 @@ enum iommu_page_response_code {
/**
* struct iommu_page_response - Generic page response information
+ * @argsz: User filled size of this data
* @version: API version of this structure
* @flags: encodes whether the corresponding fields are valid
* (IOMMU_FAULT_PAGE_RESPONSE_* values)
@@ -143,6 +144,7 @@ enum iommu_page_response_code {
* @code: response code from iommu_page_response_code
*/
struct iommu_page_response {
+ __u32 argsz;
#define IOMMU_PAGE_RESP_VERSION_1 1
__u32 version;
#define IOMMU_PAGE_RESP_PASID_VALID(1 << 0)
@@ -218,6 +220,7 @@ struct iommu_inv_pasid_info {
/**
* struct iommu_cache_invalidate_info - First level/stage invalidation
* information
+ * @argsz: User filled size of this data
* @version: API version of this structure
* @cache: bitfield that allows to select which caches to invalidate
* @granularity: defines the lowest granularity used for the invalidation:
@@ -246,6 +249,7 @@ struct iommu_inv_pasid_info {
* must support the used granularity.
*/
struct iommu_cache_invalidate_info {
+ __u32 argsz;
#define IOMMU_CACHE_INVALIDATE_INFO_VERSION_1 1
__u32 version;
/* IOMMU paging structure cache */
@@ -292,6 +296,7 @@ struct iommu_gpasid_bind_data_vtd {
/**
* struct iommu_gpasid_bind_data - Information about device and guest PASID
binding
+ * @argsz: User filled size of this data
* @version: Version of this data structure
* @format:PASID table entry format
* @flags: Additional information on guest bind request
@@ -309,6 +314,7 @@ struct iommu_gpasid_bind_data_vtd {
* PASID to host PASID based on this bind data.
*/
struct iommu_gpasid_bind_data {
+ __u32 argsz;
#define IOMMU_GPASID_BIND_VERSION_11
__u32 version;
#define IOMMU_PASID_FORMAT_INTEL_VTD 1
--
2.7.4
[PATCH v2 0/3] IOMMU user API enhancement
IOMMU user API header was introduced to support nested DMA translation and related fault handling. The current UAPI data structures consist of three areas that cover the interactions between host kernel and guest: - fault handling - cache invalidation - bind guest page tables, i.e. guest PASID Future extensions are likely to support more architectures and vIOMMU features. In the previous discussion, using user-filled data size and feature flags is made a preferred approach over a unified version number. https://lkml.org/lkml/2020/1/29/45 In addition to introduce argsz field to data structures, this patchset is also trying to document the UAPI design, usage, and extension rules. VT-d driver changes to utilize the new argsz field is included, VFIO usage is to follow. Thanks, Jacob Changeog: v2: - Removed unified API version and helper - Introduced argsz for each UAPI data - Introduced UAPI doc Jacob Pan (3): docs: IOMMU user API iommu/uapi: Add argsz for user filled data iommu/vt-d: Sanity check uapi argsz filled by users Documentation/userspace-api/iommu.rst | 210 ++ drivers/iommu/intel-iommu.c | 16 +++ drivers/iommu/intel-svm.c | 12 ++ include/uapi/linux/iommu.h| 6 + 4 files changed, 244 insertions(+) create mode 100644 Documentation/userspace-api/iommu.rst -- 2.7.4
[PATCH v2 1/3] docs: IOMMU user API
IOMMU UAPI is newly introduced to support communications between guest virtual IOMMU and host IOMMU. There has been lots of discussions on how it should work with VFIO UAPI and userspace in general. This document is indended to clarify the UAPI design and usage. The mechenics of how future extensions should be achieved are also covered in this documentation. Signed-off-by: Liu Yi L Signed-off-by: Jacob Pan --- Documentation/userspace-api/iommu.rst | 210 ++ 1 file changed, 210 insertions(+) create mode 100644 Documentation/userspace-api/iommu.rst diff --git a/Documentation/userspace-api/iommu.rst b/Documentation/userspace-api/iommu.rst new file mode 100644 index ..e95dc5a04a41 --- /dev/null +++ b/Documentation/userspace-api/iommu.rst @@ -0,0 +1,210 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. iommu: + += +IOMMU Userspace API += + +IOMMU UAPI is used for virtualization cases where communications are +needed between physical and virtual IOMMU drivers. For native +usage, IOMMU is a system device which does not need to communicate +with user space directly. + +The primary use cases are guest Shared Virtual Address (SVA) and +guest IO virtual address (IOVA), wherein virtual IOMMU (vIOMMU) is +required to communicate with the physical IOMMU in the host. + +.. contents:: :local: + +Functionalities + +Communications of user and kernel involve both directions. The +supported user-kernel APIs are as follows: + +1. Alloc/Free PASID +2. Bind/unbind guest PASID (e.g. Intel VT-d) +3. Bind/unbind guest PASID table (e.g. ARM sMMU) +4. Invalidate IOMMU caches +5. Service page request + +Requirements + +The IOMMU UAPIs are generic and extensible to meet the following +requirements: + +1. Emulated and para-virtualised vIOMMUs +2. Multiple vendors (Intel VT-d, ARM sMMU, etc.) +3. Extensions to the UAPI shall not break existing user space + +Interfaces + +Although the data structures defined in IOMMU UAPI are self-contained, +there is no user API functions introduced. Instead, IOMMU UAPI is +designed to work with existing user driver frameworks such as VFIO. + +Extension Rules & Precautions +- +When IOMMU UAPI gets extended, the data structures can *only* be +modified in two ways: + +1. Adding new fields by re-purposing the padding[] field. No size change. +2. Adding new union members at the end. May increase in size. + +No new fields can be added *after* the variable size union in that it +will break backward compatibility when offset moves. In both cases, a +new flag must be accompanied with a new field such that the IOMMU +driver can process the data based on the new flag. Version field is +only reserved for the unlikely event of UAPI upgrade at its entirety. + +It's *always* the caller's responsibility to indicate the size of the +structure passed by setting argsz appropriately. + +When IOMMU UAPI extension results in size increase, user such as VFIO +has to handle the following scenarios: + +1. User and kernel has exact size match +2. An older user with older kernel header (smaller UAPI size) running on a + newer kernel (larger UAPI size) +3. A newer user with newer kernel header (larger UAPI size) running + on a older kernel. +4. A malicious/misbehaving user pass illegal/invalid size but within + range. The data may contain garbage. + + +Feature Checking + +While launching a guest with vIOMMU, it is important to ensure that host +can support the UAPI data structures to be used for vIOMMU-pIOMMU +communications. Without the upfront compatibility checking, future +faults are difficult to report even in normal conditions. For example, +TLB invalidations should always succeed from vIOMMU's +perspective. There is no architectural way to report back to the vIOMMU +if the UAPI data is incompatible. For this reason the following IOMMU +UAPIs cannot fail: + +1. Free PASID +2. Unbind guest PASID +3. Unbind guest PASID table (SMMU) +4. Cache invalidate +5. Page response + +User applications such as QEMU is expected to import kernel UAPI +headers. Only backward compatibility is supported. For example, an +older QEMU (with older kernel header) can run on newer kernel. Newer +QEMU (with new kernel header) may fail on older kernel. + +IOMMU vendor driver should report the below features to IOMMU UAPI +consumers (e.g. via VFIO). + +1. IOMMU_NESTING_FEAT_SYSWIDE_PASID +2. IOMMU_NESTING_FEAT_BIND_PGTBL +3. IOMMU_NESTING_FEAT_BIND_PASID_TABLE +4. IOMMU_NESTING_FEAT_CACHE_INVLD +5. IOMMU_NESTING_FEAT_PAGE_REQUEST + +Take VFIO as example, upon request from VFIO user space (e.g. QEMU), +VFIO kernel code shall query IOMMU vendor driver for the support of +the above features. Query result can then be reported back to the
[GIT PULL] Crypto Fixes for 5.8
Hi Linus: This push contains a number of fixes to the omap and nitrox drivers. The following changes since commit 58ca0060ec4e51208d2eee12198fc55fd9e4feb3: crypto: hisilicon - fix driver compatibility issue with different versions of devices (2020-05-28 17:27:52 +1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus for you to fetch changes up to 320bdbd816156f9ca07e5fed7bfb449f2908dda7: crypto: cavium/nitrox - Fix 'nitrox_get_first_device()' when ndevlist is fully iterated (2020-06-04 22:06:26 +1000) Christophe JAILLET (1): crypto: cavium/nitrox - Fix 'nitrox_get_first_device()' when ndevlist is fully iterated Tero Kristo (7): crypto: omap-aes - avoid spamming console with self tests crypto: omap-sham - force kernel driver usage for sha algos crypto: omap-crypto - fix userspace copied buffer access crypto: omap-sham - huge buffer access fixes crypto: omap-sham - fix very small data size handling crypto: omap-aes - prevent unregistering algorithms twice crypto: omap-sham - add proper load balancing support for multicore drivers/crypto/cavium/nitrox/nitrox_main.c | 4 ++-- drivers/crypto/omap-aes-gcm.c | 1 - drivers/crypto/omap-aes.c | 8 ++-- drivers/crypto/omap-crypto.c | 10 -- drivers/crypto/omap-sham.c | 101 ++--- 5 files changed, 74 insertions(+), 50 deletions(-) Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH v2 3/3] iommu/vt-d: Sanity check uapi argsz filled by users
IOMMU UAPI data has an argsz field which is filled by user. As the data structures expands, argsz may change. As the UAPI data are shared among different architectures, extensions of UAPI data could be a result of one architecture which has no impact on another. Therefore, these argsz santity checks are performed in the model specific IOMMU drivers. This patch adds sanity checks in the VT-d to ensure argsz passed by userspace matches feature flags and other contents. Signed-off-by: Jacob Pan --- drivers/iommu/intel-iommu.c | 16 drivers/iommu/intel-svm.c | 12 2 files changed, 28 insertions(+) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 27ebf4b9faef..c98b5109684b 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -5365,6 +5365,7 @@ intel_iommu_sva_invalidate(struct iommu_domain *domain, struct device *dev, struct device_domain_info *info; struct intel_iommu *iommu; unsigned long flags; + unsigned long minsz; int cache_type; u8 bus, devfn; u16 did, sid; @@ -5385,6 +5386,21 @@ intel_iommu_sva_invalidate(struct iommu_domain *domain, struct device *dev, if (!(dmar_domain->flags & DOMAIN_FLAG_NESTING_MODE)) return -EINVAL; + minsz = offsetofend(struct iommu_cache_invalidate_info, padding); + if (inv_info->argsz < minsz) + return -EINVAL; + + /* Sanity check user filled invalidation dat sizes */ + if (inv_info->granularity == IOMMU_INV_GRANU_ADDR && + inv_info->argsz != offsetofend(struct iommu_cache_invalidate_info, + addr_info)) + return -EINVAL; + + if (inv_info->granularity == IOMMU_INV_GRANU_PASID && + inv_info->argsz != offsetofend(struct iommu_cache_invalidate_info, + pasid_info)) + return -EINVAL; + spin_lock_irqsave(_domain_lock, flags); spin_lock(>lock); info = get_domain_info(dev); diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c index 35b43fe819ed..64dc2c66dfff 100644 --- a/drivers/iommu/intel-svm.c +++ b/drivers/iommu/intel-svm.c @@ -235,15 +235,27 @@ int intel_svm_bind_gpasid(struct iommu_domain *domain, struct device *dev, struct dmar_domain *dmar_domain; struct intel_svm_dev *sdev; struct intel_svm *svm; + unsigned long minsz; int ret = 0; if (WARN_ON(!iommu) || !data) return -EINVAL; + /* +* We mandate that no size change in IOMMU UAPI data before the +* variable size union at the end. +*/ + minsz = offsetofend(struct iommu_gpasid_bind_data, padding); + if (data->argsz < minsz) + return -EINVAL; + if (data->version != IOMMU_GPASID_BIND_VERSION_1 || data->format != IOMMU_PASID_FORMAT_INTEL_VTD) return -EINVAL; + if (data->argsz != offsetofend(struct iommu_gpasid_bind_data, vtd)) + return -EINVAL; + if (!dev_is_pci(dev)) return -ENOTSUPP; -- 2.7.4
Fund Application For Project
Asalam - alikom, I apologise for sending an unexpected message, We are an expert in Finance, Investments and Assets Collateralization. We offer loan / project funding at a low interest rate of 2.5% RIO per anum. Kindly revert back if interested for further proceedings and negotiations. Yours Faithfully, Mr. Hamad Jassim Al Darwish
[git pull] drm i915 fixes for rc1
Hi Linus, dhowells reported an oops, and the i915 team tracked it down to a missing fix that didn't have correct tags, they've pulled it in along with two other fixes. I might have some more fixes for rc1, but I might not, taking the day off tomorrow, so probably won't be in a hurry to process anything new unless something urgent lands. Thanks, Dave. drm-next-2020-06-11: drm i915 fixes for 5.8-rc1 i915: - Avoid use after free in cmdparser - Avoid NULL dereference when probing all display encoders - Fixup to module parameter type The following changes since commit 8d286e2ff4400d313955b4203fc640ca6fd9228b: Merge tag 'drm-intel-next-fixes-2020-06-04' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2020-06-08 11:59:57 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-06-11 for you to fetch changes up to addb1e23bf72c47a3e2eb7cdad6dc8cdffa91384: Merge tag 'drm-intel-next-fixes-2020-06-10' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2020-06-11 11:49:04 +1000) drm i915 fixes for 5.8-rc1 i915: - Avoid use after free in cmdparser - Avoid NULL dereference when probing all display encoders - Fixup to module parameter type Chris Wilson (2): drm/i915/gem: Mark the buffer pool as active for the cmdparser drm/i915/display: Only query DP state of a DDI encoder Dave Airlie (1): Merge tag 'drm-intel-next-fixes-2020-06-10' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Jani Nikula (1): drm/i915/params: fix i915.reset module param type drivers/gpu/drm/i915/display/intel_dp.c| 3 ++ drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 56 ++ drivers/gpu/drm/i915/i915_params.c | 2 +- 3 files changed, 52 insertions(+), 9 deletions(-)
linux-next: Tree for Jun 11
Hi all,
News: The merge window has opened, so please do *not* add v5.9 material
to your linux-next included branches until after v5.8-rc1 has been
released.
Changes since 20200610:
My fixes tree contains:
4cb4bfffe2c1 ("device_cgroup: Fix RCU list debugging warning")
The tip tree gained conflicts against Linus' tree.
Non-merge commits (relative to Linus' tree): 1531
2039 files changed, 256836 insertions(+), 24595 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 324 trees (counting Linus' and 82 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (79ca035d2d94 Merge branch 'proc-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace)
Merging fixes/master (df8cb0ea9423 device_cgroup: Fix RCU list debugging
warning)
Merging kbuild-current/fixes (57755ccdf246 kbuild: make module name conflict a
warning again)
Merging arc-current/for-curr (9d9368e839c2 ARC: [arcompact] fix bitrot with 2
levels of interrupt)
Merging arm-current/fixes (3866f217aaa8 ARM: 8977/1: ptrace: Fix mask for thumb
breakpoint hook)
Merging arm-soc-fixes/arm/fixes (99706d62fb50 Merge tag
'omap-for-v5.7/cpsw-fixes-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes)
Merging uniphier-fixes/fixes (0e698dfa2822 Linux 5.7-rc4)
Merging arm64-fixes/for-next/fixes (ba051f097fc3 arm64/kernel: Fix return value
when cpu_online() fails in __cpu_up())
Merging m68k-current/for-linus (3381df095419 m68k: tools: Replace zero-length
array with flexible-array member)
Merging powerpc-fixes/fixes (2f26ed1764b4 powerpc/64s: Disable sanitisers for C
syscall/interrupt entry/exit code)
Merging s390-fixes/fixes (3d77e6a8804a Linux 5.7)
Merging sparc/master (af7b4801030c Merge
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net)
Merging fscrypt-current/for-stable (2b4eae95c736 fscrypt: don't evict dirty
inodes after removing key)
Merging net/master (5969856ae8ce mptcp: fix races between shutdown and recvmsg)
CONFLICT (content): Merge conflict in net/ipv4/tcp.c
Merging bpf/master (47f6bc4ce1ff tools, bpf: Do not force gcc as CC)
Merging ipsec/master (a4902d914e50 xfrm: merge fixup for "remove output_finish
indirection from xfrm_state_afinfo")
Merging netfilter/master (c3829285b2e6 netfilter: nft_set_pipapo: Disable
preemption before getting per-CPU pointer)
Merging ipvs/master (bdc48fa11e46 checkpatch/coding-style: deprecate 80-column
warning)
Merging wireless-drivers/master (f92f26f2ed2c iwlwifi: pcie: handle QuZ configs
with killer NICs as well)
Merging mac80211/master (59d4bfc1e2c0 net: fix wiki website url mac80211 and
wireless files)
Merging rdma-fixes/for-rc (3d77e6a8804a Linux 5.7)
Merging sound-current/for-linus (a4f55d927d33 Merge tag 'asoc-fix-v5.8' of
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging sound-asoc-fixes/for-linus (9d8b6b458660 Merge remote-tracking branch
'asoc/for-5.8' into asoc-linus)
Merging regmap-fixes/for-linus (7e295e6576af Merge remote-tracking branch
'regmap/for-5.8' into regmap-linus)
Merging regulator-fixes/for-linus (5fb565b69dab Merge remote-tracking branch
'regulator/for-5.8' into regulator-linus)
Merging spi-fixes/for-linus (3580c8a2d813 Merge remote
[x86/mm] c7b2a6d1af: kernel_BUG_at_arch/x86/mm/physaddr.c
Greeting,
FYI, we noticed the following commit (built with gcc-9):
commit: c7b2a6d1affb732cdb37677f31cc8c2499fbf57c ("[PATCHv2 1/2] x86/mm: Fix
boot with some memory above MAXMEM")
url:
https://github.com/0day-ci/linux/commits/Kirill-A-Shutemov/x86-Fix-boot-with-some-memory-above-MAXMEM/20200608-205827
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+-+--++
| | v5.7-rc7 |
c7b2a6d1af |
+-+--++
| boot_successes | 35 | 0
|
| boot_failures | 3| 12
|
| BUG:unable_to_handle_page_fault_for_address | 1|
|
| Oops:#[##] | 1|
|
| invoked_oom-killer:gfp_mask=0x | 2|
|
| Mem-Info| 2|
|
| Out_of_memory_and_no_killable_processes | 2|
|
| Kernel_panic-not_syncing:System_is_deadlocked_on_memory | 2|
|
| kernel_BUG_at_arch/x86/mm/physaddr.c| 0| 12
|
| invalid_opcode:#[##]| 0| 12
|
| EIP:__phys_addr | 0| 12
|
| Kernel_panic-not_syncing:Fatal_exception| 0| 12
|
+-+--++
If you fix the issue, kindly add following tag
Reported-by: kernel test robot
[0.270304] kernel BUG at arch/x86/mm/physaddr.c:81!
[0.271167] invalid opcode: [#1] SMP
[0.271930] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
5.7.0-rc7-1-gc7b2a6d1affb7 #1
[0.273438] EIP: __phys_addr+0x77/0x170
[0.274191] Code: d4 ff cf b4 00 e8 c9 69 00 00 83 05 e8 ff cf b4 01 83 15
ec ff cf b4 00 39 f0 74 3d 83 05 f0 ff cf b4 01 83 15 f4 ff cf b4 00 <0f> 0b 83
05 f8 ff cf b4 01 83 15 fc ff cf b4 00 83 05 00 00 d0 b4
[0.277762] EAX: 0fff EBX: f73fdfff ECX: f000 EDX: 0001
[0.279012] ESI: 473fdfff EDI: EBP: b44fde34 ESP: b44fde2c
[0.280216] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 EFLAGS: 00210246
[0.281576] CR0: 80050033 CR2: CR3: 04cc2000 CR4: 00040690
[0.282634] Call Trace:
[0.283117] memtype_kernel_map_sync+0x2e/0x130
[0.283995] ? __get_vm_area_node+0x13a/0x230
[0.284939] ? get_vm_area_caller+0x58/0x70
[0.285757] __ioremap_caller+0x2ea/0x510
[0.286734] ? walk_system_ram_range+0xb5/0x110
[0.287599] ioremap_cache+0x2f/0x40
[0.288288] ? acpi_os_map_iomem+0x34d/0x3c0
[0.289103] acpi_os_map_iomem+0x34d/0x3c0
[0.289888] acpi_os_map_memory+0x16/0x30
[0.290704] acpi_tb_acquire_table+0x4b/0x96
[0.291571] acpi_tb_validate_table+0x61/0xb9
[0.292482] acpi_tb_validate_temp_table+0x48/0x58
[0.293464] acpi_tb_verify_temp_table+0x49/0x4e1
[0.294272] ? acpi_ut_acquire_mutex+0x1d8/0x2d9
[0.295103] acpi_reallocate_root_table+0x169/0x21a
[0.296011] acpi_early_init+0x75/0x17f
[0.296723] start_kernel+0xad5/0xcf3
[0.297414] i386_start_kernel+0xc1/0xd1
[0.298209] startup_32_smp+0x15f/0x164
[0.298991] Modules linked in:
[0.299653] random: get_random_bytes called from init_oops_id+0x58/0x70 with
crng_init=0
[0.299660] ---[ end trace 0894cc2a10a079b3 ]---
To reproduce:
# build kernel
cd linux
cp config-5.7.0-rc7-1-gc7b2a6d1affb7 .config
make HOSTCC=gcc-9 CC=gcc-9 ARCH=i386 olddefconfig prepare
modules_prepare bzImage
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Rong Chen
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 5.7.0-rc7 Kernel Configuration
#
#
# Compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=90300
CONFIG_LD_VERSION=23400
CONFIG_CLANG_VERSION=0
CONFIG_CC_CAN_LINK=y
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_ASM_INLINE=y
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_TABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
#
[PATCH v2] powerpc: Remove inaccessible CMDLINE default
Since commit cbe46bd4f510 ("powerpc: remove CONFIG_CMDLINE #ifdef mess")
CONFIG_CMDLINE has always had a value regardless of CONFIG_CMDLINE_BOOL.
For example:
$ make ARCH=powerpc defconfig
$ cat .config
# CONFIG_CMDLINE_BOOL is not set
CONFIG_CMDLINE=""
When enabling CONFIG_CMDLINE_BOOL this value is kept making the 'default
"..." if CONFIG_CMDLINE_BOOL' ineffective.
$ ./scripts/config --enable CONFIG_CMDLINE_BOOL
$ cat .config
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE=""
Remove CONFIG_CMDLINE_BOOL and the inaccessible default.
Signed-off-by: Chris Packham
Reviewed-by: Christophe Leroy
---
It took me a while to get round to sending a v2, for a refresher v1 can be
found here:
http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20190802050232.22978-1-chris.pack...@alliedtelesis.co.nz/
Changes in v2:
- Rebase on top of Linus's tree
- Fix some typos in commit message
- Add review from Christophe
- Remove CONFIG_CMDLINE_BOOL
arch/powerpc/Kconfig | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9fa23eb320ff..51abc59c3334 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -859,12 +859,8 @@ config PPC_DENORMALISATION
Add support for handling denormalisation of single precision
values. Useful for bare metal only. If unsure say Y here.
-config CMDLINE_BOOL
- bool "Default bootloader kernel arguments"
-
config CMDLINE
- string "Initial kernel command string" if CMDLINE_BOOL
- default "console=ttyS0,9600 console=tty0 root=/dev/sda2" if CMDLINE_BOOL
+ string "Initial kernel command string"
default ""
help
On some platforms, there is currently no way for the boot loader to
--
2.27.0
[PATCH 2/2] spi: tools: Fix build errors
Fix the following build errors: include/linux/spi 2>&1 || true ln -sf /home/zhangqing/spi.git2/tools/spi/../../include/uapi/linux/spi/spidev.h include/linux/spi/spidev.h make -f /home/zhangqing/spi.git2/tools/build/Makefile.build dir=. obj=spidev_test make[1]: Entering directory '/home/zhangqing/spi.git2/tools/spi' CC spidev_test.o spidev_test.c: In function ‘transfer’: spidev_test.c:131:13: error: ‘SPI_TX_OCTAL’ undeclared (first use in this function) if (mode & SPI_TX_OCTAL) ^ spidev_test.c:131:13: note: each undeclared identifier is reported only once for each function it appears in spidev_test.c:137:13: error: ‘SPI_RX_OCTAL’ undeclared (first use in this function) if (mode & SPI_RX_OCTAL) ^ spidev_test.c: In function ‘parse_opts’: spidev_test.c:290:12: error: ‘SPI_TX_OCTAL’ undeclared (first use in this function) mode |= SPI_TX_OCTAL; ^ spidev_test.c:308:12: error: ‘SPI_RX_OCTAL’ undeclared (first use in this function) mode |= SPI_RX_OCTAL; ^ LD spidev_test-in.o ld: cannot find spidev_test.o: No such file or directory /home/zhangqing/spi.git2/tools/build/Makefile.build:144: recipe for target 'spidev_test-in.o' failed make[1]: *** [spidev_test-in.o] Error 1 make[1]: Leaving directory '/home/zhangqing/spi.git2/tools/spi' Makefile:39: recipe for target 'spidev_test-in.o' failed make: *** [spidev_test-in.o] Error 2 Signed-off-by: Qing Zhang --- include/uapi/linux/spi/spidev.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/uapi/linux/spi/spidev.h b/include/uapi/linux/spi/spidev.h index ee0f246..8b04c62 100644 --- a/include/uapi/linux/spi/spidev.h +++ b/include/uapi/linux/spi/spidev.h @@ -48,6 +48,8 @@ #define SPI_TX_QUAD0x200 #define SPI_RX_DUAL0x400 #define SPI_RX_QUAD0x800 +#defineSPI_TX_OCTAL0x2000 +#defineSPI_RX_OCTAL0x4000 /*---*/ -- 2.1.0
[PATCH 1/2] spi: tools: Make default_tx/rx and input_tx static
Fix the following sparse warning:
./spidev_test.c:50:9: warning: symbol 'default_tx' was not declared. Should it
be static?
./spidev_test.c:59:9: warning: symbol 'default_rx' was not declared. Should it
be static?
./spidev_test.c:60:6: warning: symbol 'input_tx' was not declared. Should it be
static?
Signed-off-by: Qing Zhang
---
tools/spi/spidev_test.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/spi/spidev_test.c b/tools/spi/spidev_test.c
index 56ea053f..83844f8 100644
--- a/tools/spi/spidev_test.c
+++ b/tools/spi/spidev_test.c
@@ -47,7 +47,7 @@ static int transfer_size;
static int iterations;
static int interval = 5; /* interval in seconds for showing transfer rate */
-uint8_t default_tx[] = {
+static uint8_t default_tx[] = {
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
0x40, 0x00, 0x00, 0x00, 0x00, 0x95,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
@@ -56,8 +56,8 @@ uint8_t default_tx[] = {
0xF0, 0x0D,
};
-uint8_t default_rx[ARRAY_SIZE(default_tx)] = {0, };
-char *input_tx;
+static uint8_t default_rx[ARRAY_SIZE(default_tx)] = {0, };
+static char *input_tx;
static void hex_dump(const void *src, size_t length, size_t line_size,
char *prefix)
--
2.1.0
RE: [PATCH v2] exfat: add missing brelse() calls on error paths
> If the second exfat_get_dentry() call fails then we need to release "old_bh"
> before returning. There
> is a similar bug in exfat_move_file().
>
> Fixes: 5f2aa075070c ("exfat: add inode operations")
> Reported-by: Markus Elfring
> Signed-off-by: Dan Carpenter
Applied. Thanks!
Re: [PATCH 2/2] net: dsa: qca8k: Improve SGMII interface handling
On 6/10/2020 12:15 PM, Jonathan McDowell wrote:
> This patch improves the handling of the SGMII interface on the QCA8K
> devices. Previously the driver did no configuration of the port, even if
> it was selected. We now configure it up in the appropriate
> PHY/MAC/Base-X mode depending on what phylink tells us we are connected
> to and ensure it is enabled.
>
> Tested with a device where the CPU connection is RGMII (i.e. the common
> current use case) + one where the CPU connection is SGMII. I don't have
> any devices where the SGMII interface is brought out to something other
> than the CPU.
>
> Signed-off-by: Jonathan McDowell
> ---
> drivers/net/dsa/qca8k.c | 28 +++-
> drivers/net/dsa/qca8k.h | 13 +
> 2 files changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/dsa/qca8k.c b/drivers/net/dsa/qca8k.c
> index dcd9e8fa99b6..33e62598289e 100644
> --- a/drivers/net/dsa/qca8k.c
> +++ b/drivers/net/dsa/qca8k.c
> @@ -681,7 +681,7 @@ qca8k_phylink_mac_config(struct dsa_switch *ds, int port,
> unsigned int mode,
>const struct phylink_link_state *state)
> {
> struct qca8k_priv *priv = ds->priv;
> - u32 reg;
> + u32 reg, val;
>
> switch (port) {
> case 0: /* 1st CPU port */
> @@ -740,6 +740,32 @@ qca8k_phylink_mac_config(struct dsa_switch *ds, int
> port, unsigned int mode,
> case PHY_INTERFACE_MODE_1000BASEX:
> /* Enable SGMII on the port */
> qca8k_write(priv, reg, QCA8K_PORT_PAD_SGMII_EN);
> +
> + /* Enable/disable SerDes auto-negotiation as necessary */
> + val = qca8k_read(priv, QCA8K_REG_PWS);
> + if (phylink_autoneg_inband(mode))
> + val &= ~QCA8K_PWS_SERDES_AEN_DIS;
> + else
> + val |= QCA8K_PWS_SERDES_AEN_DIS;
> + qca8k_write(priv, QCA8K_REG_PWS, val);
> +
> + /* Configure the SGMII parameters */
> + val = qca8k_read(priv, QCA8K_REG_SGMII_CTRL);
> +
> + val |= QCA8K_SGMII_EN_PLL | QCA8K_SGMII_EN_RX |
> + QCA8K_SGMII_EN_TX | QCA8K_SGMII_EN_SD;
> +
> + val &= ~QCA8K_SGMII_MODE_CTRL_MASK;
> + if (dsa_is_cpu_port(ds, port)) {
> + /* CPU port, we're talking to the CPU MAC, be a PHY */
> + val |= QCA8K_SGMII_MODE_CTRL_PHY;
Since port 6 can be interfaced to an external PHY, do not you have to
differentiate here whether this port is connected to an actual PHY,
versus connected to a MAC? You should be able to use mode == MLO_AN_PHY
to differentiate that case from the others.
> + } else if (state->interface == PHY_INTERFACE_MODE_SGMII) {
> + val |= QCA8K_SGMII_MODE_CTRL_MAC;
> + } else {
> + val |= QCA8K_SGMII_MODE_CTRL_BASEX;
Better make this explicit and check for PHY_INTERFACE_MODE_1000BASEX,
even if those are the only two possible values covered by this part of
the case statement.
--
Florian
drivers/video/fbdev/tdfxfb.c:1120:27: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: b29482fde649c72441d5478a4ea2c52c56d97a5e commit: 80591e61a0f7e88deaada69844e4a31280c4a38f kbuild: tell sparse about the $ARCH date: 7 months ago config: s390-randconfig-s032-20200611 (attached as .config) compiler: s390-linux-gcc (GCC) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.1-247-gcadbd124-dirty git checkout 80591e61a0f7e88deaada69844e4a31280c4a38f # save the attached .config to linux build tree make W=1 C=1 ARCH=s390 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/video/fbdev/tdfxfb.c:1120:27: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected void *p @@ got >> unsigned char [noderef] [usertype] *cursorbase @@ >> drivers/video/fbdev/tdfxfb.c:1120:27: sparse: expected void *p drivers/video/fbdev/tdfxfb.c:1120:27: sparse: got unsigned char [noderef] [usertype] *cursorbase drivers/video/fbdev/tdfxfb.c:1131:33: sparse: sparse: cast removes address space '' of expression drivers/video/fbdev/tdfxfb.c:1134:33: sparse: sparse: cast removes address space '' of expression include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] val @@ got restricted __le32 [usertype] @@ include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] val include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype] include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] val @@ got restricted __le32 [usertype] @@ include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] val include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype] include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] val @@ got restricted __le32 [usertype] @@ include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] val include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype] include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] val @@ got restricted __le32 [usertype] @@ include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] val include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype] include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] val @@ got restricted __le32 [usertype] @@ include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] val include/asm-generic/io.h:225:22: sparse: got
[PATCH 5/6] spi: altera: move driver name string to header file
This allows other driver to reuse the name string for spi-altera
platform device creation.
Signed-off-by: Matthew Gerlach
Signed-off-by: Wu Hao
Signed-off-by: Xu Yilun
Signed-off-by: Russ Weight
---
drivers/spi/spi-altera.c | 6 ++
include/linux/spi/altera.h | 2 ++
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-altera.c b/drivers/spi/spi-altera.c
index 8d47c57..2c12c7a 100644
--- a/drivers/spi/spi-altera.c
+++ b/drivers/spi/spi-altera.c
@@ -19,8 +19,6 @@
#include
#include
-#define DRV_NAME "spi_altera"
-
#define ALTERA_SPI_RXDATA 0
#define ALTERA_SPI_TXDATA 4
#define ALTERA_SPI_STATUS 8
@@ -338,7 +336,7 @@ MODULE_DEVICE_TABLE(of, altera_spi_match);
static struct platform_driver altera_spi_driver = {
.probe = altera_spi_probe,
.driver = {
- .name = DRV_NAME,
+ .name = ALTERA_SPI_DRV_NAME,
.pm = NULL,
.of_match_table = of_match_ptr(altera_spi_match),
},
@@ -348,4 +346,4 @@ module_platform_driver(altera_spi_driver);
MODULE_DESCRIPTION("Altera SPI driver");
MODULE_AUTHOR("Thomas Chou ");
MODULE_LICENSE("GPL");
-MODULE_ALIAS("platform:" DRV_NAME);
+MODULE_ALIAS("platform:" ALTERA_SPI_DRV_NAME);
diff --git a/include/linux/spi/altera.h b/include/linux/spi/altera.h
index 164ab7b..6539371 100644
--- a/include/linux/spi/altera.h
+++ b/include/linux/spi/altera.h
@@ -9,6 +9,8 @@
#include
#include
+#define ALTERA_SPI_DRV_NAME"spi-altera"
+
/**
* struct altera_spi_platform_data - Platform data of the Altera SPI driver
* @mode_bits: Mode bits of SPI master.
--
2.7.4
[PATCH 6/6] spi: altera: fix size mismatch on 64 bit processors
From: Matthew Gerlach
The spi-altera driver was originally written with a 32
bit processor, where sizeof(unsigned long) is 4. On a
64 bit processor sizeof(unsigned long) is 8. Change the structure
member to u32 to match the actual size of the control
register.
Signed-off-by: Matthew Gerlach
---
drivers/spi/spi-altera.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-altera.c b/drivers/spi/spi-altera.c
index 2c12c7a..468fbd5 100644
--- a/drivers/spi/spi-altera.c
+++ b/drivers/spi/spi-altera.c
@@ -46,7 +46,7 @@ struct altera_spi {
int len;
int count;
int bytes_per_word;
- unsigned long imr;
+ u32 imr;
/* data buffers */
const unsigned char *tx;
--
2.7.4
[PATCH 1/6] spi: altera: add 32bit data width transfer support.
Add support for 32bit width data register, then it supports 32bit data width spi slave device and spi transfers. Signed-off-by: Xu Yilun Signed-off-by: Wu Hao Signed-off-by: Matthew Gerlach Signed-off-by: Russ Weight --- drivers/spi/spi-altera.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/spi/spi-altera.c b/drivers/spi/spi-altera.c index 41d71ba..d5fa0c5 100644 --- a/drivers/spi/spi-altera.c +++ b/drivers/spi/spi-altera.c @@ -86,6 +86,13 @@ static void altera_spi_tx_word(struct altera_spi *hw) txd = (hw->tx[hw->count * 2] | (hw->tx[hw->count * 2 + 1] << 8)); break; + case 4: + txd = (hw->tx[hw->count * 4] + | (hw->tx[hw->count * 4 + 1] << 8) + | (hw->tx[hw->count * 4 + 2] << 16) + | (hw->tx[hw->count * 4 + 3] << 24)); + break; + } } @@ -106,6 +113,13 @@ static void altera_spi_rx_word(struct altera_spi *hw) hw->rx[hw->count * 2] = rxd; hw->rx[hw->count * 2 + 1] = rxd >> 8; break; + case 4: + hw->rx[hw->count * 4] = rxd; + hw->rx[hw->count * 4 + 1] = rxd >> 8; + hw->rx[hw->count * 4 + 2] = rxd >> 16; + hw->rx[hw->count * 4 + 3] = rxd >> 24; + break; + } } -- 2.7.4
[PATCH 0/6] Add more configuration and regmap support for spi-altera
This patchset adds platform_data for spi-altera, to enable more IP configurations, and creating specific spi client devices. It also adds regmap support, to enable the indirect access to this IP. We have a PCIE based FPGA platform which integrates this IP to communicate with a BMC chip (Intel MAX10) over SPI. The IP is configured as 32bit data width. There is also an indirect access interface in FPGA for host to access the registers of this IP. This patchset enables this use case. Matthew Gerlach (1): spi: altera: fix size mismatch on 64 bit processors Xu Yilun (5): spi: altera: add 32bit data width transfer support. spi: altera: add SPI core parameters support via platform data. spi: altera: add platform data for slave information. spi: altera: use regmap instead of direct mmio register access spi: altera: move driver name string to header file drivers/spi/Kconfig| 1 + drivers/spi/spi-altera.c | 161 + include/linux/spi/altera.h | 37 +++ 3 files changed, 171 insertions(+), 28 deletions(-) create mode 100644 include/linux/spi/altera.h -- 2.7.4
[PATCH 2/6] spi: altera: add SPI core parameters support via platform data.
This patch introduced SPI core parameters in platform data, it
allows passing these SPI core parameters via platform data.
Signed-off-by: Wu Hao
Signed-off-by: Xu Yilun
Signed-off-by: Matthew Gerlach
Signed-off-by: Russ Weight
---
drivers/spi/spi-altera.c | 25 ++---
include/linux/spi/altera.h | 24
2 files changed, 46 insertions(+), 3 deletions(-)
create mode 100644 include/linux/spi/altera.h
diff --git a/drivers/spi/spi-altera.c b/drivers/spi/spi-altera.c
index d5fa0c5..e6e6708 100644
--- a/drivers/spi/spi-altera.c
+++ b/drivers/spi/spi-altera.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -40,6 +41,8 @@
#define ALTERA_SPI_CONTROL_IE_MSK 0x100
#define ALTERA_SPI_CONTROL_SSO_MSK 0x400
+#define ALTERA_SPI_MAX_CS 32
+
struct altera_spi {
void __iomem *base;
int irq;
@@ -182,6 +185,7 @@ static irqreturn_t altera_spi_irq(int irq, void *dev)
static int altera_spi_probe(struct platform_device *pdev)
{
+ struct altera_spi_platform_data *pdata = dev_get_platdata(>dev);
struct altera_spi *hw;
struct spi_master *master;
int err = -ENODEV;
@@ -192,9 +196,24 @@ static int altera_spi_probe(struct platform_device *pdev)
/* setup the master state. */
master->bus_num = pdev->id;
- master->num_chipselect = 16;
- master->mode_bits = SPI_CS_HIGH;
- master->bits_per_word_mask = SPI_BPW_RANGE_MASK(1, 16);
+
+ if (pdata) {
+ if (pdata->num_chipselect > ALTERA_SPI_MAX_CS) {
+ dev_err(>dev,
+ "Invalid number of chipselect: %hu\n",
+ pdata->num_chipselect);
+ return -EINVAL;
+ }
+
+ master->num_chipselect = pdata->num_chipselect;
+ master->mode_bits = pdata->mode_bits;
+ master->bits_per_word_mask = pdata->bits_per_word_mask;
+ } else {
+ master->num_chipselect = 16;
+ master->mode_bits = SPI_CS_HIGH;
+ master->bits_per_word_mask = SPI_BPW_RANGE_MASK(1, 16);
+ }
+
master->dev.of_node = pdev->dev.of_node;
master->transfer_one = altera_spi_txrx;
master->set_cs = altera_spi_set_cs;
diff --git a/include/linux/spi/altera.h b/include/linux/spi/altera.h
new file mode 100644
index 000..344a3fc
--- /dev/null
+++ b/include/linux/spi/altera.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Header File for Altera SPI Driver.
+ */
+#ifndef __LINUX_SPI_ALTERA_H
+#define __LINUX_SPI_ALTERA_H
+
+#include
+#include
+#include
+
+/**
+ * struct altera_spi_platform_data - Platform data of the Altera SPI driver
+ * @mode_bits: Mode bits of SPI master.
+ * @num_chipselect:Number of chipselects.
+ * @bits_per_word_mask:bitmask of supported bits_per_word for
transfers.
+ */
+struct altera_spi_platform_data {
+ u16 mode_bits;
+ u16 num_chipselect;
+ u32 bits_per_word_mask;
+};
+
+#endif /* __LINUX_SPI_ALTERA_H */
--
2.7.4
Re: [patch 113/131] mm: balance LRU lists based on relative thrashing
在 2020/6/10 下午1:23, Joonsoo Kim 写道: > 2020년 6월 9일 (화) 오후 11:46, Johannes Weiner 님이 작성: >> >> On Tue, Jun 09, 2020 at 05:15:33PM +0800, Alex Shi wrote: >>> >>> >>> 在 2020/6/4 上午7:03, Andrew Morton 写道: + /* XXX: Move to lru_cache_add() when it supports new vs putback */ >>> >>> Hi Hannes, >>> >>> Sorry for a bit lost, would you like to explain a bit more of your idea >>> here? >>> + spin_lock_irq(_pgdat(page)->lru_lock); + lru_note_cost(page); + spin_unlock_irq(_pgdat(page)->lru_lock); + >>> >>> >>> What could we see here w/o the lru_lock? Why I want to know the lru_lock protection here is that currently we have 5 lru lists but only guarded by one lock, that would cause much contention when different apps active on a server. I guess originally we have only one lru_lock, since 5 locks would cause cacheline bouncing if we put them together, or a bit cacheline waste to separate them in cacheline. But after we have qspinlock, each of cpu will just loop lock on their cacheline, no interfer to others. It would much much relief the performance drop by cacheline bounce. And we could use page.mapping bits to store the using lru list index for the page. As a quick thought, I guess, except the 5 locks for 5 lists, we still need 1 more lock for common lruvec data or for others which relay on lru_lock now, like mlock, hpage_nr_pages.. That's the reason I want to know everything under lru_lock. :) Any comments for this idea? :) Thanks Alex >> >> It'll just be part of the existing LRU locking in >> pagevec_lru_move_fn(), when the new pages are added to the LRU in >> batch. See this older patch for example: >> >> https://lore.kernel.org/linux-mm/20160606194836.3624-6-han...@cmpxchg.org/ >> >> I didn't include it in this series to reduce conflict with Joonsoo's >> WIP series that also operates in this area and does something similar: > > Thanks! > >> https://lkml.org/lkml/2020/4/3/63 > > I haven't completed the rebase of my series but I guess that referenced patch > "https://lkml.org/lkml/2020/4/3/63; would be removed in the next version. Thanks a lot for the info, Johannes! A long history for a interesting idea. :) > > Before the I/O cost model, a new anonymous page contributes to the LRU reclaim > balance. But, now, a new anonymous page doesn't contributes to the I/O cost > so this adjusting patch would not be needed anymore. > > If anyone wants to change this part, > "/* XXX: Move to lru_cache_add() when it supports new vs putback */", feel > free > to do it.
[PATCH 3/6] spi: altera: add platform data for slave information.
This patch introduces platform data for slave information, it allows
spi-altera to add new spi devices once master registration is done.
Signed-off-by: Wu Hao
Signed-off-by: Xu Yilun
Signed-off-by: Matthew Gerlach
Signed-off-by: Russ Weight
---
drivers/spi/spi-altera.c | 11 +++
include/linux/spi/altera.h | 5 +
2 files changed, 16 insertions(+)
diff --git a/drivers/spi/spi-altera.c b/drivers/spi/spi-altera.c
index e6e6708..aa9d1a2 100644
--- a/drivers/spi/spi-altera.c
+++ b/drivers/spi/spi-altera.c
@@ -189,6 +189,7 @@ static int altera_spi_probe(struct platform_device *pdev)
struct altera_spi *hw;
struct spi_master *master;
int err = -ENODEV;
+ u16 i;
master = spi_alloc_master(>dev, sizeof(struct altera_spi));
if (!master)
@@ -244,6 +245,16 @@ static int altera_spi_probe(struct platform_device *pdev)
err = devm_spi_register_master(>dev, master);
if (err)
goto exit;
+
+ if (pdata) {
+ for (i = 0; i < pdata->num_devices; i++) {
+ if (!spi_new_device(master, pdata->devices + i))
+ dev_warn(>dev,
+"unable to create SPI device: %s\n",
+pdata->devices[i].modalias);
+ }
+ }
+
dev_info(>dev, "base %p, irq %d\n", hw->base, hw->irq);
return 0;
diff --git a/include/linux/spi/altera.h b/include/linux/spi/altera.h
index 344a3fc..2d42641 100644
--- a/include/linux/spi/altera.h
+++ b/include/linux/spi/altera.h
@@ -14,11 +14,16 @@
* @mode_bits: Mode bits of SPI master.
* @num_chipselect:Number of chipselects.
* @bits_per_word_mask:bitmask of supported bits_per_word for
transfers.
+ * @num_devices: Number of devices that shall be added when the driver
+ * is probed.
+ * @devices: The devices to add.
*/
struct altera_spi_platform_data {
u16 mode_bits;
u16 num_chipselect;
u32 bits_per_word_mask;
+ u16 num_devices;
+ struct spi_board_info *devices;
};
#endif /* __LINUX_SPI_ALTERA_H */
--
2.7.4
[PATCH 4/6] spi: altera: use regmap instead of direct mmio register access
This patch adds support for regmap. It allows this driver to
be compatible if low layer register access method is changed
in some cases.
Signed-off-by: Matthew Gerlach
Signed-off-by: Wu Hao
Signed-off-by: Xu Yilun
Signed-off-by: Russ Weight
---
drivers/spi/Kconfig| 1 +
drivers/spi/spi-altera.c | 103 -
include/linux/spi/altera.h | 6 +++
3 files changed, 90 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 8f1f8fc..6d79fc7 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -59,6 +59,7 @@ comment "SPI Master Controller Drivers"
config SPI_ALTERA
tristate "Altera SPI Controller"
+ select REGMAP_MMIO
help
This is the driver for the Altera SPI Controller.
diff --git a/drivers/spi/spi-altera.c b/drivers/spi/spi-altera.c
index aa9d1a2..8d47c57 100644
--- a/drivers/spi/spi-altera.c
+++ b/drivers/spi/spi-altera.c
@@ -44,7 +44,6 @@
#define ALTERA_SPI_MAX_CS 32
struct altera_spi {
- void __iomem *base;
int irq;
int len;
int count;
@@ -54,8 +53,45 @@ struct altera_spi {
/* data buffers */
const unsigned char *tx;
unsigned char *rx;
+
+ struct regmap *regmap;
+ u32 base;
+
+ struct device *dev;
+};
+
+static const struct regmap_config spi_altera_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .fast_io = true,
};
+static int altr_spi_writel(struct altera_spi *hw, unsigned int reg,
+ unsigned int val)
+{
+ int ret;
+
+ ret = regmap_write(hw->regmap, hw->base + reg, val);
+ if (ret)
+ dev_err(hw->dev, "fail to write reg 0x%x val 0x%x: %d\n",
+ reg, val, ret);
+
+ return ret;
+}
+
+static int altr_spi_readl(struct altera_spi *hw, unsigned int reg,
+ unsigned int *val)
+{
+ int ret;
+
+ ret = regmap_read(hw->regmap, hw->base + reg, val);
+ if (ret)
+ dev_err(hw->dev, "fail to read reg 0x%x: %d\n", reg, ret);
+
+ return ret;
+}
+
static inline struct altera_spi *altera_spi_to_hw(struct spi_device *sdev)
{
return spi_master_get_devdata(sdev->master);
@@ -67,12 +103,13 @@ static void altera_spi_set_cs(struct spi_device *spi, bool
is_high)
if (is_high) {
hw->imr &= ~ALTERA_SPI_CONTROL_SSO_MSK;
- writel(hw->imr, hw->base + ALTERA_SPI_CONTROL);
- writel(0, hw->base + ALTERA_SPI_SLAVE_SEL);
+ altr_spi_writel(hw, ALTERA_SPI_CONTROL, hw->imr);
+ altr_spi_writel(hw, ALTERA_SPI_SLAVE_SEL, 0);
} else {
- writel(BIT(spi->chip_select), hw->base + ALTERA_SPI_SLAVE_SEL);
+ altr_spi_writel(hw, ALTERA_SPI_SLAVE_SEL,
+ BIT(spi->chip_select));
hw->imr |= ALTERA_SPI_CONTROL_SSO_MSK;
- writel(hw->imr, hw->base + ALTERA_SPI_CONTROL);
+ altr_spi_writel(hw, ALTERA_SPI_CONTROL, hw->imr);
}
}
@@ -99,14 +136,14 @@ static void altera_spi_tx_word(struct altera_spi *hw)
}
}
- writel(txd, hw->base + ALTERA_SPI_TXDATA);
+ altr_spi_writel(hw, ALTERA_SPI_TXDATA, txd);
}
static void altera_spi_rx_word(struct altera_spi *hw)
{
unsigned int rxd;
- rxd = readl(hw->base + ALTERA_SPI_RXDATA);
+ altr_spi_readl(hw, ALTERA_SPI_RXDATA, );
if (hw->rx) {
switch (hw->bytes_per_word) {
case 1:
@@ -133,6 +170,7 @@ static int altera_spi_txrx(struct spi_master *master,
struct spi_device *spi, struct spi_transfer *t)
{
struct altera_spi *hw = spi_master_get_devdata(master);
+ u32 val;
hw->tx = t->tx_buf;
hw->rx = t->rx_buf;
@@ -143,7 +181,7 @@ static int altera_spi_txrx(struct spi_master *master,
if (hw->irq >= 0) {
/* enable receive interrupt */
hw->imr |= ALTERA_SPI_CONTROL_IRRDY_MSK;
- writel(hw->imr, hw->base + ALTERA_SPI_CONTROL);
+ altr_spi_writel(hw, ALTERA_SPI_CONTROL, hw->imr);
/* send the first byte */
altera_spi_tx_word(hw);
@@ -151,9 +189,13 @@ static int altera_spi_txrx(struct spi_master *master,
while (hw->count < hw->len) {
altera_spi_tx_word(hw);
- while (!(readl(hw->base + ALTERA_SPI_STATUS) &
-ALTERA_SPI_STATUS_RRDY_MSK))
+ for (;;) {
+ altr_spi_readl(hw, ALTERA_SPI_STATUS, );
+ if (val & ALTERA_SPI_STATUS_RRDY_MSK)
+ break;
+
cpu_relax();
+ }
altera_spi_rx_word(hw);
[PATCH] ext4: fix spelling mistakes in extents.c
Fix spelling issues over the comments in the code. requsted ==> requested deterimined ==> determined insde ==> inside neet ==> need somthing ==> something Signed-off-by: Keyur Patel --- fs/ext4/extents.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 7d088ff1e902..8028e1aae8de 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -1915,7 +1915,7 @@ static unsigned int ext4_ext_check_overlap(struct ext4_sb_info *sbi, /* * ext4_ext_insert_extent: - * tries to merge requsted extent into the existing extent or + * tries to merge requested extent into the existing extent or * inserts requested extent as new one into the tree, * creating new leaf in the no-space case. */ @@ -3125,7 +3125,7 @@ static int ext4_ext_zeroout(struct inode *inode, struct ext4_extent *ex) * * * Splits extent [a, b] into two extents [a, @split) and [@split, b], states - * of which are deterimined by split_flag. + * of which are determined by split_flag. * * There are two cases: * a> the extent are splitted into two extent. @@ -3650,7 +3650,7 @@ static int ext4_split_convert_extents(handle_t *handle, eof_block = map->m_lblk + map->m_len; /* * It is safe to convert extent to initialized via explicit -* zeroout only if extent is fully insde i_size or new_size. +* zeroout only if extent is fully inside i_size or new_size. */ depth = ext_depth(inode); ex = path[depth].p_ext; @@ -4495,7 +4495,7 @@ static long ext4_zero_range(struct file *file, loff_t offset, } /* -* Round up offset. This is not fallocate, we neet to zero out +* Round up offset. This is not fallocate, we need to zero out * blocks, so convert interior block aligned part of the range to * unwritten and possibly manually zero out unaligned parts of the * range. @@ -5579,7 +5579,7 @@ ext4_swap_extents(handle_t *handle, struct inode *inode1, } ex1 = path1[path1->p_depth].p_ext; ex2 = path2[path2->p_depth].p_ext; - /* Do we have somthing to swap ? */ + /* Do we have something to swap ? */ if (unlikely(!ex2 || !ex1)) goto finish; -- 2.26.2
[PATCH v2] f2fs: add F2FS_IOC_SEC_TRIM_FILE ioctl
From: Daeho Jeong
Added a new ioctl to send discard commands or/and zero out
to whole data area of a regular file for security reason.
Signed-off-by: Daeho Jeong
---
fs/f2fs/f2fs.h | 8 +++
fs/f2fs/file.c | 143 +
2 files changed, 151 insertions(+)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index c812fb8e2d9c..ca139fac5a73 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -434,6 +434,7 @@ static inline bool __has_cursum_space(struct f2fs_journal
*journal,
_IOR(F2FS_IOCTL_MAGIC, 18, __u64)
#define F2FS_IOC_RESERVE_COMPRESS_BLOCKS \
_IOR(F2FS_IOCTL_MAGIC, 19, __u64)
+#define F2FS_IOC_SEC_TRIM_FILE _IOW(F2FS_IOCTL_MAGIC, 20, __u32)
#define F2FS_IOC_GET_VOLUME_NAME FS_IOC_GETFSLABEL
#define F2FS_IOC_SET_VOLUME_NAME FS_IOC_SETFSLABEL
@@ -453,6 +454,13 @@ static inline bool __has_cursum_space(struct f2fs_journal
*journal,
#define F2FS_GOING_DOWN_METAFLUSH 0x3 /* going down with meta flush */
#define F2FS_GOING_DOWN_NEED_FSCK 0x4 /* going down to trigger fsck */
+/*
+ * Flags used by F2FS_IOC_SEC_TRIM_FILE
+ */
+#define F2FS_TRIM_FILE_DISCARD 0x1 /* send discard command */
+#define F2FS_TRIM_FILE_ZEROOUT 0x2 /* zero out */
+#define F2FS_TRIM_FILE_MASK0x3
+
#if defined(__KERNEL__) && defined(CONFIG_COMPAT)
/*
* ioctl commands in 32 bit emulation
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index dfa1ac2d751a..ba9b7ec5d6bf 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -3749,6 +3749,146 @@ static int f2fs_reserve_compress_blocks(struct file
*filp, unsigned long arg)
return ret;
}
+static int f2fs_secure_erase(struct block_device *bdev, block_t block,
+ block_t len, u32 flags)
+{
+ struct request_queue *q = bdev_get_queue(bdev);
+ sector_t sector = SECTOR_FROM_BLOCK(block);
+ sector_t nr_sects = SECTOR_FROM_BLOCK(len);
+ int ret = 0;
+
+ if (!q)
+ return -ENXIO;
+
+ if (flags & F2FS_TRIM_FILE_DISCARD)
+ ret = blkdev_issue_discard(bdev, sector, nr_sects, GFP_NOFS,
+ blk_queue_secure_erase(q) ?
+ BLKDEV_DISCARD_SECURE : 0);
+
+ if (!ret && (flags & F2FS_TRIM_FILE_ZEROOUT))
+ ret = blkdev_issue_zeroout(bdev, sector, nr_sects, GFP_NOFS, 0);
+
+ return ret;
+}
+
+static int f2fs_sec_trim_file(struct file *filp, unsigned long arg)
+{
+ struct inode *inode = file_inode(filp);
+ struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
+ struct address_space *mapping = inode->i_mapping;
+ struct block_device *prev_bdev = NULL;
+ pgoff_t index, pg_start = 0, pg_end;
+ block_t prev_block = 0, len = 0;
+ u32 flags;
+ int ret = 0;
+
+ if (!(filp->f_mode & FMODE_WRITE))
+ return -EBADF;
+
+ if (get_user(flags, (u32 __user *)arg))
+ return -EFAULT;
+ if (flags == 0 || (flags & ~F2FS_TRIM_FILE_MASK))
+ return -EINVAL;
+
+ if ((flags & F2FS_TRIM_FILE_DISCARD) && !f2fs_hw_support_discard(sbi))
+ return -EOPNOTSUPP;
+
+ file_start_write(filp);
+ inode_lock(inode);
+
+ if (!S_ISREG(inode->i_mode) || f2fs_is_atomic_file(inode) ||
+ f2fs_compressed_file(inode)) {
+ ret = -EINVAL;
+ goto err;
+ }
+
+ if (!inode->i_size)
+ goto err;
+ pg_end = DIV_ROUND_UP(inode->i_size, PAGE_SIZE);
+
+ ret = f2fs_convert_inline_inode(inode);
+ if (ret)
+ goto err;
+
+ down_write(_I(inode)->i_gc_rwsem[WRITE]);
+ down_write(_I(inode)->i_mmap_sem);
+
+ ret = filemap_write_and_wait(mapping);
+ if (ret)
+ goto out;
+
+ truncate_inode_pages(mapping, 0);
+
+ for (index = pg_start; index < pg_end;) {
+ struct dnode_of_data dn;
+ unsigned int end_offset;
+
+ set_new_dnode(, inode, NULL, NULL, 0);
+ ret = f2fs_get_dnode_of_data(, index, LOOKUP_NODE);
+ if (ret)
+ goto out;
+
+ end_offset = ADDRS_PER_PAGE(dn.node_page, inode);
+ if (pg_end < end_offset + index)
+ end_offset = pg_end - index;
+
+ for (; dn.ofs_in_node < end_offset;
+ dn.ofs_in_node++, index++) {
+ struct block_device *cur_bdev;
+ block_t blkaddr = f2fs_data_blkaddr();
+
+ if (__is_valid_data_blkaddr(blkaddr)) {
+ if (!f2fs_is_valid_blkaddr(F2FS_I_SB(inode),
+ blkaddr, DATA_GENERIC_ENHANCE)) {
+
Re: [PATCH 1/2] net: dsa: qca8k: Switch to PHYLINK instead of PHYLIB
On 6/10/2020 12:14 PM, Jonathan McDowell wrote: > Update the driver to use the new PHYLINK callbacks, removing the > legacy adjust_link callback. > > Signed-off-by: Jonathan McDowell This looks reasonable to me, Russell would be the person you want to get an Acked-by/Reviewed-by tag from. -- Florian
Re: [PATCH] Replace HTTP links with HTTPS ones: Documentation/translations/it_IT
On Wed, Jun 10, 2020 at 08:11:39PM +0200, Alexander A. Klimov wrote: > Am 10.06.20 um 10:57 schrieb Federico Vaga: > > On Tuesday, June 9, 2020 10:12:41 PM CEST Alexander A. Klimov wrote: > > > Rationale: > > > Reduces attack surface on kernel devs opening the links for MITM > > > as HTTPS traffic is much harder to manipulate. > > > > > > Deterministic algorithm: > > > For each file: > > >For each line: > > > If doesn't contain `\bxmlns\b`: > > >For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: > > > If both the HTTP and HTTPS versions > > > return 200 OK and serve the same content: > > >Replace HTTP with HTTPS. Is this script somewhere we can read it? (It's easier usually to review the code for bulk changes than the bulk changes themselves.) > > > > > > Signed-off-by: Alexander A. Klimov > > > --- > > > .../translations/it_IT/admin-guide/README.rst | 2 +- > > > .../translations/it_IT/doc-guide/parse-headers.rst | 2 +- > > > .../translations/it_IT/doc-guide/sphinx.rst| 10 +- > > > .../translations/it_IT/process/2.Process.rst | 12 ++-- > > > .../translations/it_IT/process/3.Early-stage.rst | 2 +- > > > .../translations/it_IT/process/4.Coding.rst| 4 ++-- > > > .../it_IT/process/7.AdvancedTopics.rst | 8 > > > .../translations/it_IT/process/8.Conclusion.rst| 14 +++--- > > > .../translations/it_IT/process/adding-syscalls.rst | 4 ++-- > > > .../translations/it_IT/process/changes.rst | 6 +++--- > > > .../translations/it_IT/process/clang-format.rst| 2 +- > > > .../translations/it_IT/process/coding-style.rst| 2 +- > > > Documentation/translations/it_IT/process/howto.rst | 2 +- > > > .../it_IT/process/maintainer-pgp-guide.rst | 2 +- > > > .../it_IT/process/submitting-patches.rst | 4 ++-- > > > .../it_IT/process/volatile-considered-harmful.rst | 4 ++-- > > > 16 files changed, 40 insertions(+), 40 deletions(-) > > > > > > > > > > diff --git a/Documentation/translations/it_IT/doc-guide/sphinx.rst > > > b/Documentation/translations/it_IT/doc-guide/sphinx.rst index > > > f1ad4504b734..0aaeb0297661 100644 > > > --- a/Documentation/translations/it_IT/doc-guide/sphinx.rst > > > +++ b/Documentation/translations/it_IT/doc-guide/sphinx.rst > > > @@ -14,7 +14,7 @@ Per generare la documentazione in HTML o PDF, usate > > > comandi ``make htmldocs`` o ``make pdfdocs``. La documentazione così > > > generata sarà disponibile nella cartella ``Documentation/output``. > > > > > > -.. _Sphinx: http://www.sphinx-doc.org/ > > > +.. _Sphinx: https://www.sphinx-doc.org/ > > > .. _reStructuredText: http://docutils.sourceforge.net/rst.html > > > > It is not part of the deterministic algorithm but you may consider this as > > well Why did it not match? > > > > -.. _reStructuredText: http://docutils.sourceforge.net/rst.html > > +.. _reStructuredText: https://docutils.sourceforge.io/rst.html > > > I'll think about analyzing such almost-matches, extending the algo and > supplying a second round of patches once all [1] of this round arrive in > torvalds/master. > > [1]: > > ➜ linux git:(feature/https-links-3) ✗ git diff --shortstat > 1963 files changed, 2882 insertions(+), 2882 deletions(-) > ➜ linux git:(feature/https-links-3) ✗ Is there a reason to do this one language at a time instead of just doing everything in one go? -- Kees Cook
Re: [PATCH] s390: protvirt: virtio: Refuse device without IOMMU
On 2020/6/10 下午9:11, Pierre Morel wrote: Protected Virtualisation protects the memory of the guest and do not allow a the host to access all of its memory. Let's refuse a VIRTIO device which does not use IOMMU protected access. Signed-off-by: Pierre Morel --- drivers/s390/virtio/virtio_ccw.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c index 5730572b52cd..06ffbc96587a 100644 --- a/drivers/s390/virtio/virtio_ccw.c +++ b/drivers/s390/virtio/virtio_ccw.c @@ -986,6 +986,11 @@ static void virtio_ccw_set_status(struct virtio_device *vdev, u8 status) if (!ccw) return; + /* Protected Virtualisation guest needs IOMMU */ + if (is_prot_virt_guest() && + !__virtio_test_bit(vdev, VIRTIO_F_IOMMU_PLATFORM)) + status &= ~VIRTIO_CONFIG_S_FEATURES_OK; + /* Write the status to the host. */ vcdev->dma_area->status = status; ccw->cmd_code = CCW_CMD_WRITE_STATUS; I wonder whether we need move it to virtio core instead of ccw. I think the other memory protection technologies may suffer from this as well. Thanks
[PATCH] f2fs: add F2FS_IOC_SEC_TRIM_FILE ioctl
From: Daeho Jeong
Added a new ioctl to send discard commands or/and zero out
to whole data area of a regular file for security reason.
Signed-off-by: Daeho Jeong
---
fs/f2fs/f2fs.h | 8 +++
fs/f2fs/file.c | 143 +
2 files changed, 151 insertions(+)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index c812fb8e2d9c..ca139fac5a73 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -434,6 +434,7 @@ static inline bool __has_cursum_space(struct f2fs_journal
*journal,
_IOR(F2FS_IOCTL_MAGIC, 18, __u64)
#define F2FS_IOC_RESERVE_COMPRESS_BLOCKS \
_IOR(F2FS_IOCTL_MAGIC, 19, __u64)
+#define F2FS_IOC_SEC_TRIM_FILE _IOW(F2FS_IOCTL_MAGIC, 20, __u32)
#define F2FS_IOC_GET_VOLUME_NAME FS_IOC_GETFSLABEL
#define F2FS_IOC_SET_VOLUME_NAME FS_IOC_SETFSLABEL
@@ -453,6 +454,13 @@ static inline bool __has_cursum_space(struct f2fs_journal
*journal,
#define F2FS_GOING_DOWN_METAFLUSH 0x3 /* going down with meta flush */
#define F2FS_GOING_DOWN_NEED_FSCK 0x4 /* going down to trigger fsck */
+/*
+ * Flags used by F2FS_IOC_SEC_TRIM_FILE
+ */
+#define F2FS_TRIM_FILE_DISCARD 0x1 /* send discard command */
+#define F2FS_TRIM_FILE_ZEROOUT 0x2 /* zero out */
+#define F2FS_TRIM_FILE_MASK0x3
+
#if defined(__KERNEL__) && defined(CONFIG_COMPAT)
/*
* ioctl commands in 32 bit emulation
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index dfa1ac2d751a..ba9b7ec5d6bf 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -3749,6 +3749,146 @@ static int f2fs_reserve_compress_blocks(struct file
*filp, unsigned long arg)
return ret;
}
+static int f2fs_secure_erase(struct block_device *bdev, block_t block,
+ block_t len, u32 flags)
+{
+ struct request_queue *q = bdev_get_queue(bdev);
+ sector_t sector = SECTOR_FROM_BLOCK(block);
+ sector_t nr_sects = SECTOR_FROM_BLOCK(len);
+ int ret = 0;
+
+ if (!q)
+ return -ENXIO;
+
+ if (flags & F2FS_TRIM_FILE_DISCARD)
+ ret = blkdev_issue_discard(bdev, sector, nr_sects, GFP_NOFS,
+ blk_queue_secure_erase(q) ?
+ BLKDEV_DISCARD_SECURE : 0);
+
+ if (!ret && (flags & F2FS_TRIM_FILE_ZEROOUT))
+ ret = blkdev_issue_zeroout(bdev, sector, nr_sects, GFP_NOFS, 0);
+
+ return ret;
+}
+
+static int f2fs_sec_trim_file(struct file *filp, unsigned long arg)
+{
+ struct inode *inode = file_inode(filp);
+ struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
+ struct address_space *mapping = inode->i_mapping;
+ struct block_device *prev_bdev = NULL;
+ pgoff_t index, pg_start = 0, pg_end;
+ block_t prev_block = 0, len = 0;
+ u32 flags;
+ int ret = 0;
+
+ if (!(filp->f_mode & FMODE_WRITE))
+ return -EBADF;
+
+ if (get_user(flags, (u32 __user *)arg))
+ return -EFAULT;
+ if (flags == 0 || (flags & ~F2FS_TRIM_FILE_MASK))
+ return -EINVAL;
+
+ if ((flags & F2FS_TRIM_FILE_DISCARD) && !f2fs_hw_support_discard(sbi))
+ return -EOPNOTSUPP;
+
+ file_start_write(filp);
+ inode_lock(inode);
+
+ if (!S_ISREG(inode->i_mode) || f2fs_is_atomic_file(inode) ||
+ f2fs_compressed_file(inode)) {
+ ret = -EINVAL;
+ goto err;
+ }
+
+ if (!inode->i_size)
+ goto err;
+ pg_end = DIV_ROUND_UP(inode->i_size, PAGE_SIZE);
+
+ ret = f2fs_convert_inline_inode(inode);
+ if (ret)
+ goto err;
+
+ down_write(_I(inode)->i_gc_rwsem[WRITE]);
+ down_write(_I(inode)->i_mmap_sem);
+
+ ret = filemap_write_and_wait(mapping);
+ if (ret)
+ goto out;
+
+ truncate_inode_pages(mapping, 0);
+
+ for (index = pg_start; index < pg_end;) {
+ struct dnode_of_data dn;
+ unsigned int end_offset;
+
+ set_new_dnode(, inode, NULL, NULL, 0);
+ ret = f2fs_get_dnode_of_data(, index, LOOKUP_NODE);
+ if (ret)
+ goto out;
+
+ end_offset = ADDRS_PER_PAGE(dn.node_page, inode);
+ if (pg_end < end_offset + index)
+ end_offset = pg_end - index;
+
+ for (; dn.ofs_in_node < end_offset;
+ dn.ofs_in_node++, index++) {
+ struct block_device *cur_bdev;
+ block_t blkaddr = f2fs_data_blkaddr();
+
+ if (__is_valid_data_blkaddr(blkaddr)) {
+ if (!f2fs_is_valid_blkaddr(F2FS_I_SB(inode),
+ blkaddr, DATA_GENERIC_ENHANCE)) {
+
Re: Compile error: linux-next-20200610
On 6/10/20 8:07 PM, Souptick Joarder wrote: > Hi Stephen, > > While compiling linux-next-20200610, I hit below compile error. > .config file is attached. > > Steps -> > > 1. Download the tar > 2. make defconfig > 3. make -j4 > > In file included from drivers/firmware/efi/libstub/efi-stub-helper.c:16:0: > drivers/firmware/efi/libstub/efi-stub-helper.c: In function ‘efi_char16_puts’: > ./arch/x86/include/asm/efi.h:355:3: sorry, unimplemented: ms_abi > attribute requires -maccumulate-outgoing-args or subtarget > optimization implying it >: __efi64_thunk_map(inst, func, inst, ##__VA_ARGS__)) >^ > drivers/firmware/efi/libstub/efi-stub-helper.c:37:2: note: in > expansion of macro ‘efi_call_proto’ > efi_call_proto(efi_table_attr(efi_system_table, con_out), > ^ > drivers/firmware/efi/libstub/efi-stub-helper.c:37: confused by earlier > errors, bailing out > Preprocessed source stored into /tmp/ccZ7rSjc.out file, please attach > this to your bugreport. > make[5]: *** [drivers/firmware/efi/libstub/efi-stub-helper.o] Error 1 > make[4]: *** [drivers/firmware/efi/libstub] Error 2 > make[3]: *** [drivers/firmware/efi] Error 2 > make[2]: *** [drivers/firmware] Error 2 > make[1]: *** [drivers] Error 2 > make[1]: *** Waiting for unfinished jobs > make: *** [__sub-make] Error 2 > > -Souptick > Patch is here: https://lore.kernel.org/bpf/20200605150638.1011637-1-nived...@alum.mit.edu/ thanks. -- ~Randy Reported-by: Randy Dunlap
Re: [PATCH RFC v6 02/11] vhost: use batched get_vq_desc version
On 2020/6/10 下午7:05, Michael S. Tsirkin wrote:
+EXPORT_SYMBOL_GPL(vhost_get_vq_desc);
/* Reverse the effect of vhost_get_vq_desc. Useful for error handling. */
void vhost_discard_vq_desc(struct vhost_virtqueue *vq, int n)
{
+ unfetch_descs(vq);
vq->last_avail_idx -= n;
So unfetch_descs() has decreased last_avail_idx.
Can we fix this by letting unfetch_descs() return the number and then we can
do:
int d = unfetch_descs(vq);
vq->last_avail_idx -= (n > d) ? n - d: 0;
Thanks
That's intentional I think - we need both.
Yes, but:
Unfetch_descs drops the descriptors in the cache that were
*not returned to caller* through get_vq_desc.
vhost_discard_vq_desc drops the ones that were returned through get_vq_desc.
Did I miss anything?
We could count some descriptors twice, consider the case e.g we only
cache on descriptor:
fetch_descs()
fetch_buf()
last_avail_idx++;
Then we want do discard it:
vhost_discard_avail_buf(1)
unfetch_descs()
last_avail_idx--;
last_avail_idx -= 1;
Thanks
Re: [kernfs] ea7c5fc39a: stress-ng.stream.ops_per_sec 11827.2% improvement
On Thu, 2020-06-11 at 10:06 +0800, kernel test robot wrote:
> On Sun, Jun 07, 2020 at 09:13:08AM +0800, Ian Kent wrote:
> > On Sat, 2020-06-06 at 20:18 +0200, Greg Kroah-Hartman wrote:
> > > On Sat, Jun 06, 2020 at 11:52:16PM +0800, kernel test robot
> > > wrote:
> > > > Greeting,
> > > >
> > > > FYI, we noticed a 11827.2% improvement of stress-
> > > > ng.stream.ops_per_sec due to commit:
> > > >
> > > >
> > > > commit: ea7c5fc39ab005b501e0c7666c29db36321e4f74 ("[PATCH 1/4]
> > > > kernfs: switch kernfs to use an rwsem")
> > > > url:
> > > > https://github.com/0day-ci/linux/commits/Ian-Kent/kernfs-proposed-locking-and-concurrency-improvement/20200525-134849
> > > >
> > >
> > > Seriously? That's a huge performance increase, and one that
> > > feels
> > > really odd. Why would a stress-ng test be touching sysfs?
> >
> > That is unusually high even if there's a lot of sysfs or kernfs
> > activity and that patch shouldn't improve VFS path walk contention
> > very much even if it is present.
> >
> > Maybe I've missed something, and the information provided doesn't
> > seem to be quite enough to even make a start on it.
> >
> > That's going to need some analysis which, for my part, will need to
> > wait probably until around rc1 time frame to allow me to get
> > through
> > the push down stack (reactive, postponed due to other priorities)
> > of
> > jobs I have in order to get back to the fifo queue (longer term
> > tasks,
> > of which this is one) list of jobs I need to do as well, ;)
> >
> > Please, kernel test robot, more information about this test and
> > what
> > it's doing.
> >
>
> Hi Ian,
>
> We increased the timeout of stress-ng from 1s to 32s, and there's
> only
> 3% improvement of stress-ng.stream.ops_per_sec:
>
> fefcfc968723caf9 ea7c5fc39ab005b501e0c7666c testcase/testparams/tes
> tbox
> -- ---
>
> %stddev change %stddev
> \ |\
> 10686 3% 11037stress-ng/cpu-cache-
> performance-1HDD-100%-32s-ucode=0x52c/lkp-csl-2sp5
> 10686 3% 11037GEO-MEAN stress-
> ng.stream.ops_per_sec
>
> It seems the result of stress-ng is inaccurate if test time too
> short, we'll increase the test time to avoid unreasonable results,
> sorry for the inconvenience.
Haha, I was worried there wasn't anything that could be done to
work out what was wrong.
I had tried to reproduce it, and failed since the job file specifies
a host config that I simply don't have, and I don't get how to alter
the job to suit, or how to specify a host definition file.
I also couldn't work out what parameters where used in running the
test so I was about to ask on the lkp list after working through
this in a VM.
So your timing on looking into this is fortunate, for sure.
Thank you very much for that.
Now, Greg, there's that locking I changed around kernfs_refresh_inode()
that I need to fix which I re-considered as a result of this, so that's
a plus for the testing because it's certainly wrong.
I'll have another look at that and boot test it on a couple of systems
then post a v2 for you to consider. What I've done might offend your
sensibilities as it does mine, or perhaps not so much.
Ian
Re: [PATCH v3 1/4] fs, net: Standardize on file_receive helper to move fds across processes
On Wed, Jun 10, 2020 at 08:48:45AM +, David Laight wrote: > From: Sargun Dhillon > > Sent: 10 June 2020 09:13 > In essence the 'copy_to_user' is done by the wrapper code. > The code filling in the CMSG buffer can be considered to be > writing a kernel buffer. > > IIRC other kernels (eg NetBSD) do the copies for ioctl() requests > in the ioctl syscall wrapper. > The IOW/IOR/IOWR flags have to be right. Yeah, this seems like it'd make a lot more sense (and would have easily caught the IOR/IOW issue pointed out later in the thread). I wonder how insane it would be to try to fix that globally in the kernel... -- Kees Cook
Re: [RFC PATCH] fix use after free in xlog_wait()
On 2020/6/11 10:28, Dave Chinner wrote Actually, it's a lot simpler: thread1 thread2 __xfs_trans_commit xfs_log_commit_cil xlog_wait schedule xlog_cil_push_work wake_up_all xlog_cil_committed kmem_free remove_wait_queue spin_lock_irqsave --> UAF It's ture in this case, however, I got another result when I tried to reporduce it, which seems 'ctx' can be freed in a different path: [ 64.975996] run fstests generic/019 at 2020-06-10 16:13:44 [ 69.126208] xfs filesystem being mounted at /tmp/scratch supports timestamps until 2038 (0x7fff) [ 99.166846] XFS (sdb): log I/O error -5 [ 99.170111] XFS (sdb): Log I/O Error Detected. Shutting down filesystem [ 99.171071] XFS (sdb): Please unmount the filesystem and rectify the problem(s) [ 99.179569] [ cut here ] [ 99.180432] WARNING: CPU: 7 PID: 2705 at fs/iomap/buffered-io.c:1030 iomap_page_mkwrite_actor+0x17d/0x1b0 [ 99.181273] == [ 99.181758] Modules linked in: [ 99.182806] BUG: KASAN: use-after-free in do_raw_spin_trylock+0x67/0x180 [ 99.183255] CPU: 7 PID: 2705 Comm: fio Not tainted 5.7.0-next-20200602+ #29 [ 99.184166] Read of size 4 at addr 888115f28868 by task fio/2704 [ 99.184171] [ 99.185142] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ 99.185995] CPU: 6 PID: 2704 Comm: fio Not tainted 5.7.0-next-20200602+ #29 [ 99.186227] RIP: 0010:iomap_page_mkwrite_actor+0x17d/0x1b0 [ 99.188199] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ 99.189178] Code: 89 ef e8 a6 d4 c7 ff e9 3f ff ff ff e8 fc 64 ad ff 89 da 31 f6 48 89 ef e8 b0 1e f2 ff 49 89 dc e9 26 ff ff ff e8 e3 64 ad ff <0f> 0b eb be e8 da 64 ad ff 4d 8d 67 ffe [ 99.189899] Call Trace: [ 99.191748] RSP: :88810599fa18 EFLAGS: 00010293 [ 99.194218] dump_stack+0xf6/0x16e [ 99.194574] RAX: 888106df3680 RBX: 1000 RCX: 94338cad [ 99.195301] ? do_raw_spin_trylock+0x67/0x180 [ 99.195777] RDX: RSI: RDI: 0001 [ 99.195786] RBP: ea0002544800 R08: 888106df3680 R09: f940004a8901 [ 99.196764] ? do_raw_spin_trylock+0x67/0x180 [ 99.196778] print_address_description.constprop.0.cold+0xd3/0x415 [ 99.197393] R10: ea0002544807 R11: f940004a8900 R12: [ 99.198380] ? do_raw_spin_trylock+0x67/0x180 [ 99.199349] R13: R14: 8880b6ee7280 R15: ea00025447c8 [ 99.199939] kasan_report.cold+0x1f/0x37 [ 99.199949] ? __switch_to+0x510/0xef0 [ 99.200812] FS: 7ff7d8562740() GS:88811a40() knlGS: [ 99.201755] ? do_raw_spin_trylock+0x67/0x180 [ 99.201765] check_memory_region+0x14e/0x1b0 [ 99.202378] CS: 0010 DS: ES: CR0: 80050033 [ 99.203319] do_raw_spin_trylock+0x67/0x180 [ 99.203858] CR2: 7ff7ae3e4ff0 CR3: 0001028be000 CR4: 06e0 [ 99.204374] ? do_raw_spin_lock+0x290/0x290 [ 99.205470] DR0: DR1: DR2: [ 99.206069] _raw_spin_lock_irqsave+0x44/0x80 [ 99.206641] DR3: DR6: fffe0ff0 DR7: 0400 [ 99.206647] Call Trace: [ 99.207420] ? remove_wait_queue+0x22/0x190 [ 99.208014] iomap_apply+0x2d7/0xc00 [ 99.208949] remove_wait_queue+0x22/0x190 [ 99.209539] ? iomap_page_create+0x350/0x350 [ 99.210510] xfs_log_commit_cil+0x1c7e/0x2940 [ 99.25] ? trace_event_raw_event_iomap_apply+0x430/0x430 [ 99.212073] ? xlog_cil_empty+0x90/0x90 [ 99.212421] ? down_write_trylock+0x2f0/0x2f0 [ 99.212979] ? check_flags.part.0+0x430/0x430 [ 99.213486] ? update_time+0xc0/0xc0 [ 99.214025] ? wake_up_q+0x140/0x140 [ 99.214610] iomap_page_mkwrite+0x26a/0x3b0 [ 99.215201] ? xlog_ticket_alloc+0x3e0/0x3e0 [ 99.215966] ? iomap_page_create+0x350/0x350 [ 99.216487] ? __kasan_kmalloc.constprop.0+0xc2/0xd0 [ 99.217097] __xfs_filemap_fault.constprop.0+0x32f/0x4e0 [ 99.217675] __xfs_trans_commit+0x2b3/0xf20 [ 99.218206] do_page_mkwrite+0x1b1/0x470 [ 99.218681] ? xfs_trans_unreserve_and_mod_sb+0xab0/0xab0 [ 99.219259] do_wp_page+0x9e7/0x1b10 [ 99.219838] ? xfs_isilocked+0x8c/0x2f0 [ 99.220439] ? finish_mkwrite_fault+0x4b0/0x4b0 [ 99.221102] ? xfs_trans_log_inode+0x1b2/0x480 [ 99.221817] ? do_user_addr_fault+0x2fd/0xd42 [ 99.222382] xfs_vn_update_time+0x40a/0x730 [ 99.222922] handle_mm_fault+0x1c9f/0x3600 [ 99.223634] ? xfs_setattr_mode.isra.0+0xb0/0xb0 [ 99.224140] ? __pmd_alloc+0x390/0x390 [ 99.224653] ? current_time+0xad/0x110 [
Re: [PATCH v3 1/4] fs, net: Standardize on file_receive helper to move fds across processes
On Wed, Jun 10, 2020 at 08:12:38AM +, Sargun Dhillon wrote:
> As an aside, all of this junk should be dropped:
> + ret = get_user(size, >size);
> + if (ret)
> + return ret;
> +
> + ret = copy_struct_from_user(, sizeof(addfd), uaddfd, size);
> + if (ret)
> + return ret;
>
> and the size member of the seccomp_notif_addfd struct. I brought this up
> off-list with Tycho that ioctls have the size of the struct embedded in them.
> We
> should just use that. The ioctl definition is based on this[2]:
> #define _IOC(dir,type,nr,size) \
> (((dir) << _IOC_DIRSHIFT) | \
>((type) << _IOC_TYPESHIFT) | \
>((nr) << _IOC_NRSHIFT) | \
>((size) << _IOC_SIZESHIFT))
>
>
> We should just use copy_from_user for now. In the future, we can either
> introduce new ioctl names for new structs, or extract the size dynamically
> from
> the ioctl (and mask it out on the switch statement in seccomp_notify_ioctl.
Yeah, that seems reasonable. Here's the diff for that part:
diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
index 7b6028b399d8..98bf19b4e086 100644
--- a/include/uapi/linux/seccomp.h
+++ b/include/uapi/linux/seccomp.h
@@ -118,7 +118,6 @@ struct seccomp_notif_resp {
/**
* struct seccomp_notif_addfd
- * @size: The size of the seccomp_notif_addfd datastructure
* @id: The ID of the seccomp notification
* @flags: SECCOMP_ADDFD_FLAG_*
* @srcfd: The local fd number
@@ -126,7 +125,6 @@ struct seccomp_notif_resp {
* @newfd_flags: The O_* flags the remote FD should have applied
*/
struct seccomp_notif_addfd {
- __u64 size;
__u64 id;
__u32 flags;
__u32 srcfd;
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 3c913f3b8451..00cbdad6c480 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -1297,14 +1297,9 @@ static long seccomp_notify_addfd(struct seccomp_filter
*filter,
struct seccomp_notif_addfd addfd;
struct seccomp_knotif *knotif;
struct seccomp_kaddfd kaddfd;
- u64 size;
int ret;
- ret = get_user(size, >size);
- if (ret)
- return ret;
-
- ret = copy_struct_from_user(, sizeof(addfd), uaddfd, size);
+ ret = copy_from_user(, uaddfd, sizeof(addfd));
if (ret)
return ret;
>
>
> +#define SECCOMP_IOCTL_NOTIF_ADDFDSECCOMP_IOR(3, \
> + struct seccomp_notif_addfd)
>
> Lastly, what I believe to be a small mistake, it should be SECCOMP_IOW, based
> on
> the documentation in ioctl.h -- "_IOW means userland is writing and kernel is
> reading."
Oh. Yeah; good catch. Uhm, that means SECCOMP_IOCTL_NOTIF_ID_VALID
is wrong too, yes? Tycho, Christian, how disruptive would this be to
fix? (Perhaps support both and deprecate the IOR version at some point
in the future?)
Diff for just addfd's change:
diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
index 7b6028b399d8..98bf19b4e086 100644
--- a/include/uapi/linux/seccomp.h
+++ b/include/uapi/linux/seccomp.h
@@ -146,7 +144,7 @@ struct seccomp_notif_addfd {
struct seccomp_notif_resp)
#define SECCOMP_IOCTL_NOTIF_ID_VALID SECCOMP_IOR(2, __u64)
/* On success, the return value is the remote process's added fd number */
-#define SECCOMP_IOCTL_NOTIF_ADDFD SECCOMP_IOR(3, \
+#define SECCOMP_IOCTL_NOTIF_ADDFD SECCOMP_IOW(3, \
struct seccomp_notif_addfd)
#endif /* _UAPI_LINUX_SECCOMP_H */
--
Kees Cook
Re: [PATCH V3] vdpa: introduce virtio pci driver
On 2020/6/10 下午4:51, Michael S. Tsirkin wrote:
On Wed, Jun 10, 2020 at 04:25:06PM +0800, Jason Wang wrote:
+
+#define VP_VDPA_FEATURES \
+ ((1ULL << VIRTIO_F_ANY_LAYOUT)| \
This is presumably for transitional devices only. In fact looking at
code it seems that only net in legacy mode accepts VIRTIO_F_ANY_LAYOUT.
Spec violation I guess ... but what should we do? Relax the spec
or fix drivers?
I don't get how it violates the spec.
Spec says transitional drivers must ack VIRTIO_F_ANY_LAYOUT
I don't see this in the spec, maybe you can point it to me?
But grep for VIRTIO_F_ANY_LAYOUT and you will see they don't.
Only legacy virtio net does.
Maybe it should have been
transitional drivers when using the lgacy interface, but there
you are.
+(1ULL << VIRTIO_F_VERSION_1) | \
+(1ULL << VIRTIO_F_ORDER_PLATFORM)| \
+(1ULL << VIRTIO_F_IOMMU_PLATFORM))
+
+struct vp_vring {
+ void __iomem *notify;
+ char msix_name[256];
+ resource_size_t notify_pa;
+ struct vdpa_callback cb;
+ int irq;
+};
+
+struct vp_vdpa {
+ struct vdpa_device vdpa;
+ struct pci_dev *pdev;
+
+ struct virtio_device_id id;
+
+ struct vp_vring vring[VP_VDPA_MAX_QUEUE];
+
+ /* The IO mapping for the PCI config space */
+ void __iomem * const *base;
+ struct virtio_pci_common_cfg __iomem *common;
+ void __iomem *device;
+ /* Base of vq notifications */
+ void __iomem *notify;
+
+ /* Multiplier for queue_notify_off. */
+ u32 notify_off_multiplier;
+
+ int modern_bars;
+ int vectors;
+};
+
+static struct vp_vdpa *vdpa_to_vp(struct vdpa_device *vdpa)
+{
+ return container_of(vdpa, struct vp_vdpa, vdpa);
+}
+
+/*
+ * Type-safe wrappers for io accesses.
+ * Use these to enforce at compile time the following spec requirement:
+ *
+ * The driver MUST access each field using the “natural” access
+ * method, i.e. 32-bit accesses for 32-bit fields, 16-bit accesses
+ * for 16-bit fields and 8-bit accesses for 8-bit fields.
+ */
+static inline u8 vp_ioread8(u8 __iomem *addr)
+{
+ return ioread8(addr);
+}
+static inline u16 vp_ioread16(__le16 __iomem *addr)
+{
+ return ioread16(addr);
+}
+
+static inline u32 vp_ioread32(__le32 __iomem *addr)
+{
+ return ioread32(addr);
+}
+
+static inline void vp_iowrite8(u8 value, u8 __iomem *addr)
+{
+ iowrite8(value, addr);
+}
+
+static inline void vp_iowrite16(u16 value, __le16 __iomem *addr)
+{
+ iowrite16(value, addr);
+}
+
+static inline void vp_iowrite32(u32 value, __le32 __iomem *addr)
+{
+ iowrite32(value, addr);
+}
+
+static void vp_iowrite64_twopart(u64 val,
+__le32 __iomem *lo, __le32 __iomem *hi)
+{
+ vp_iowrite32((u32)val, lo);
+ vp_iowrite32(val >> 32, hi);
+}
+
+static int find_capability(struct pci_dev *dev, u8 cfg_type,
+ u32 ioresource_types, int *bars)
+{
+ int pos;
+
+ for (pos = pci_find_capability(dev, PCI_CAP_ID_VNDR);
+pos > 0;
+pos = pci_find_next_capability(dev, pos, PCI_CAP_ID_VNDR)) {
+ u8 type, bar;
+
+ pci_read_config_byte(dev, pos + offsetof(struct virtio_pci_cap,
+cfg_type),
+);
+ pci_read_config_byte(dev, pos + offsetof(struct virtio_pci_cap,
+bar),
+);
+
+ /* Ignore structures with reserved BAR values */
+ if (bar > 0x5)
+ continue;
+
+ if (type == cfg_type) {
+ if (pci_resource_len(dev, bar) &&
+ pci_resource_flags(dev, bar) & ioresource_types) {
+ *bars |= (1 << bar);
+ return pos;
+ }
+ }
+ }
+ return 0;
+}
+
+static void __iomem *map_capability(struct vp_vdpa *vp_vdpa, int off,
+ resource_size_t *pa)
+{
+ struct pci_dev *pdev = vp_vdpa->pdev;
+ u32 offset;
+ u8 bar;
+
+ pci_read_config_byte(pdev,
+off + offsetof(struct virtio_pci_cap, bar),
+);
+ pci_read_config_dword(pdev,
+ off + offsetof(struct virtio_pci_cap, offset),
+ );
+
+ if (pa)
+ *pa = pci_resource_start(pdev, bar) + offset;
+
+ return vp_vdpa->base[bar] + offset;
+}
+
+static u64 vp_vdpa_get_features(struct vdpa_device *vdpa)
+{
+ struct vp_vdpa *vp_vdpa = vdpa_to_vp(vdpa);
+ u64 features;
+
+ vp_iowrite32(0, _vdpa->common->device_feature_select);
+ features = vp_ioread32(_vdpa->common->device_feature);
+
Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU
On 2020/6/10 上午12:49, Bjorn Helgaas wrote: On Tue, Jun 09, 2020 at 11:15:06AM +0200, Arnd Bergmann wrote: On Tue, Jun 9, 2020 at 6:02 AM Zhangfei Gao wrote: On 2020/6/9 上午12:41, Bjorn Helgaas wrote: On Mon, Jun 08, 2020 at 10:54:15AM +0800, Zhangfei Gao wrote: On 2020/6/6 上午7:19, Bjorn Helgaas wrote: +++ b/drivers/iommu/iommu.c @@ -2418,6 +2418,10 @@ int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode, fwspec->iommu_fwnode = iommu_fwnode; fwspec->ops = ops; dev_iommu_fwspec_set(dev, fwspec); + + if (dev_is_pci(dev)) + pci_fixup_device(pci_fixup_final, to_pci_dev(dev)); + Then pci_fixup_final will be called twice, the first in pci_bus_add_device. Here in iommu_fwspec_init is the second time, specifically for iommu_fwspec. Will send this when 5.8-rc1 is open. Wait, this whole fixup approach seems wrong to me. No matter how you do the fixup, it's still a fixup, which means it requires ongoing maintenance. Surely we don't want to have to add the Vendor/Device ID for every new AMBA device that comes along, do we? Here the fake pci device has standard PCI cfg space, but physical implementation is base on AMBA They can provide pasid feature. However, 1, does not support tlp since they are not real pci devices. 2. does not support pri, instead support stall (provided by smmu) And stall is not a pci feature, so it is not described in struct pci_dev, but in struct iommu_fwspec. So we use this fixup to tell pci system that the devices can support stall, and hereby support pasid. This did not answer my question. Are you proposing that we update a quirk every time a new AMBA device is released? I don't think that would be a good model. Yes, you are right, but we do not have any better idea yet. Currently we have three fake pci devices, which support stall and pasid. We have to let pci system know the device can support pasid, because of stall feature, though not support pri. Do you have any other ideas? It sounds like the best way would be to allocate a PCI capability for it, so detection can be done through config space, at least in future devices, or possibly after a firmware update if the config space in your system is controlled by firmware somewhere. Once there is a proper mechanism to do this, using fixups to detect the early devices that don't use that should be uncontroversial. I have no idea what the process or timeline is to add new capabilities into the PCIe specification, or if this one would be acceptable to the PCI SIG at all. That sounds like a possibility. The spec already defines a Vendor-Specific Extended Capability (PCIe r5.0, sec 7.9.5) that might be a candidate. Will investigate this, thanks Bjorn If detection cannot be done through PCI config space, the next best alternative is to pass auxiliary data through firmware. On DT based machines, you can list non-hotpluggable PCIe devices and add custom properties that could be read during device enumeration. I assume ACPI has something similar, but I have not done that. Yes, thanks Arnd ACPI has _DSM (ACPI v6.3, sec 9.1.1), which might be a candidate. I like this better than a PCI capability because the property you need to expose is not a PCI property. _DSM may not workable, since it is working in runtime. We need stall information in init stage, neither too early (after allocation of iommu_fwspec) nor too late (before arm_smmu_add_device ). By the way, It would be a long time if we need modify either pcie spec or acpi spec. Can we use pci_fixup_device in iommu_fwspec_init first, it is relatively simple and meet the requirement of platform device using pasid, and they are already in product. Thanks
Re: [PATCH] firmware: arm_scmi: fix timeout value for send_message
On Wed, Jun 10, 2020 at 10:56 AM Sudeep Holla wrote:
[I admit you can write bigger posts than me, so I am not going to
write a passionate response to each of your paragraphs.
Let's keep it to the point.]
> > > > if (xfer->hdr.poll_completion) {
> > > > - ktime_t stop = ktime_add_ns(ktime_get(),
> > > > SCMI_MAX_POLL_TO_NS);
> > > > + ktime_t stop = ktime_add_ns(ktime_get(), 500 * 1000 *
> > > > NSEC_PER_USEC);
> > > >
> > >
> > > This is unacceptable delay for schedutil fast_switch. So no for this one.
> > >
> > Increasing timeout does not increase latency.
>
> Agreed, but worst case you may be stuck here for 500ms which is not
> acceptable.
>
Not acceptable to who, you or the kernel? :)Now that you said you
are fixing the scmi's fast_switch implementation.
Even though I don't think 500ms would ruin our lives, but ok, I will
make it 30ms - same as you did in the 'else' block. And drop the other
change.
Thanks.
[PATCH] xfs: fix use-after-free on CIL context on shutdown
From: Dave Chinner
xlog_wait() on the CIL context can reference a freed context if the
waiter doesn't get scheduled before the CIL context is freed. This
can happen when a task is on the hard throttle and the CIL push
aborts due to a shutdown. This was detected by generic/019:
thread 1thread 2
__xfs_trans_commit
xfs_log_commit_cil
xlog_wait
schedule
xlog_cil_push_work
wake_up_all
xlog_cil_committed
kmem_free
remove_wait_queue
spin_lock_irqsave --> UAF
Fix it by moving the wait queue to the CIL rather than keeping it in
in the CIL context that gets freed on push completion. Because the
wait queue is now independent of the CIL context and we might have
multiple contexts in flight at once, only wake the waiters on the
push throttle when the context we are pushing is over the hard
throttle size threshold.
Fixes: 0e7ab7efe7745 ("xfs: Throttle commits on delayed background CIL push")
Reported-by: Yu Kuai
Signed-off-by: Dave Chinner
---
fs/xfs/xfs_log_cil.c | 10 +-
fs/xfs/xfs_log_priv.h | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/xfs/xfs_log_cil.c b/fs/xfs/xfs_log_cil.c
index b43f0e8f43f2e..9ed90368ab311 100644
--- a/fs/xfs/xfs_log_cil.c
+++ b/fs/xfs/xfs_log_cil.c
@@ -671,7 +671,8 @@ xlog_cil_push_work(
/*
* Wake up any background push waiters now this context is being pushed.
*/
- wake_up_all(>push_wait);
+ if (ctx->space_used >= XLOG_CIL_BLOCKING_SPACE_LIMIT(log))
+ wake_up_all(>xc_push_wait);
/*
* Check if we've anything to push. If there is nothing, then we don't
@@ -743,13 +744,12 @@ xlog_cil_push_work(
/*
* initialise the new context and attach it to the CIL. Then attach
-* the current context to the CIL committing lsit so it can be found
+* the current context to the CIL committing list so it can be found
* during log forces to extract the commit lsn of the sequence that
* needs to be forced.
*/
INIT_LIST_HEAD(_ctx->committing);
INIT_LIST_HEAD(_ctx->busy_extents);
- init_waitqueue_head(_ctx->push_wait);
new_ctx->sequence = ctx->sequence + 1;
new_ctx->cil = cil;
cil->xc_ctx = new_ctx;
@@ -937,7 +937,7 @@ xlog_cil_push_background(
if (cil->xc_ctx->space_used >= XLOG_CIL_BLOCKING_SPACE_LIMIT(log)) {
trace_xfs_log_cil_wait(log, cil->xc_ctx->ticket);
ASSERT(cil->xc_ctx->space_used < log->l_logsize);
- xlog_wait(>xc_ctx->push_wait, >xc_push_lock);
+ xlog_wait(>xc_push_wait, >xc_push_lock);
return;
}
@@ -1216,12 +1216,12 @@ xlog_cil_init(
INIT_LIST_HEAD(>xc_committing);
spin_lock_init(>xc_cil_lock);
spin_lock_init(>xc_push_lock);
+ init_waitqueue_head(>xc_push_wait);
init_rwsem(>xc_ctx_lock);
init_waitqueue_head(>xc_commit_wait);
INIT_LIST_HEAD(>committing);
INIT_LIST_HEAD(>busy_extents);
- init_waitqueue_head(>push_wait);
ctx->sequence = 1;
ctx->cil = cil;
cil->xc_ctx = ctx;
diff --git a/fs/xfs/xfs_log_priv.h b/fs/xfs/xfs_log_priv.h
index ec22c7a3867f1..75a62870b63af 100644
--- a/fs/xfs/xfs_log_priv.h
+++ b/fs/xfs/xfs_log_priv.h
@@ -240,7 +240,6 @@ struct xfs_cil_ctx {
struct xfs_log_vec *lv_chain; /* logvecs being pushed */
struct list_headiclog_entry;
struct list_headcommitting; /* ctx committing list */
- wait_queue_head_t push_wait; /* background push throttle */
struct work_struct discard_endio_work;
};
@@ -274,6 +273,7 @@ struct xfs_cil {
wait_queue_head_t xc_commit_wait;
xfs_lsn_t xc_current_sequence;
struct work_struct xc_push_work;
+ wait_queue_head_t xc_push_wait; /* background push throttle */
} cacheline_aligned_in_smp;
/*
[PATCH] drivers: dpaa2: Use devm_kcalloc() in setup_dpni()
A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "devm_kcalloc".
Signed-off-by: Xu Wang
---
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
index 8fb48de5d18c..f150cd454fa4 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
@@ -2907,8 +2907,9 @@ static int setup_dpni(struct fsl_mc_device *ls_dev)
if (err && err != -EOPNOTSUPP)
goto close;
- priv->cls_rules = devm_kzalloc(dev, sizeof(struct dpaa2_eth_cls_rule) *
- dpaa2_eth_fs_count(priv), GFP_KERNEL);
+ priv->cls_rules = devm_kcalloc(dev, dpaa2_eth_fs_count(priv),
+ sizeof(struct dpaa2_eth_cls_rule),
+ GFP_KERNEL);
if (!priv->cls_rules) {
err = -ENOMEM;
goto close;
--
2.17.1
[GIT PULL] vfs: improve DAX behavior for 5.8, part 3
Hi Linus, Please pull this third part of the 5.8 DAX changes. Now that the xfs changes have landed, this third piece changes the FS_XFLAG_DAX ioctl code in xfs to request that the inode be reloaded after the last program closes the file, if doing so would make a S_DAX change happen. This goal here is to make dax access mode switching quicker when possible. I did a test merge of this branch against upstream this evening and there weren't any conflicts. The first five patches in the series were already in the xfs merge, so it's only the last one that should change anything. Please let us know if you have any complaints about pulling this, since I can rework the branch. --D The following changes since commit 2c567af418e3f9380c2051aada58b4e5a4b5c2ad: fs: Introduce DCACHE_DONTCACHE (2020-05-13 08:44:35 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/vfs-5.8-merge-3 for you to fetch changes up to e4f9ba20d3b8c2b86ec71f326882e1a3c4e47953: fs/xfs: Update xfs_ioctl_setattr_dax_invalidate() (2020-05-29 20:13:20 -0700) Third part of new DAX code for 5.8: - Teach XFS to ask the VFS to drop an inode if the administrator changes the FS_XFLAG_DAX inode flag such that the S_DAX state would change. This can result in files changing access modes without requiring an unmount cycle. Ira Weiny (6): fs/xfs: Remove unnecessary initialization of i_rwsem fs/xfs: Change XFS_MOUNT_DAX to XFS_MOUNT_DAX_ALWAYS fs/xfs: Make DAX mount option a tri-state fs/xfs: Create function xfs_inode_should_enable_dax() fs/xfs: Combine xfs_diflags_to_linux() and xfs_diflags_to_iflags() fs/xfs: Update xfs_ioctl_setattr_dax_invalidate() fs/xfs/xfs_icache.c | 4 +- fs/xfs/xfs_inode.h | 1 + fs/xfs/xfs_ioctl.c | 141 fs/xfs/xfs_iops.c | 70 +- fs/xfs/xfs_mount.h | 4 +- fs/xfs/xfs_super.c | 48 -- 6 files changed, 115 insertions(+), 153 deletions(-)
[PATCH] Fix null pointer dereference in vector_user_bpf
The bpf_prog is being checked for !NULL after uml_kmalloc but
later its used directly for example:
bpf_prog->filter = bpf and is also later returned upon success.
Fix this, do a NULL check and return right away.
Signed-off-by: Gaurav Singh
---
arch/um/drivers/vector_user.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/um/drivers/vector_user.c b/arch/um/drivers/vector_user.c
index aa28e9eecb7b..71d043ae306f 100644
--- a/arch/um/drivers/vector_user.c
+++ b/arch/um/drivers/vector_user.c
@@ -730,10 +730,12 @@ void *uml_vector_user_bpf(char *filename)
return false;
}
bpf_prog = uml_kmalloc(sizeof(struct sock_fprog), UM_GFP_KERNEL);
- if (bpf_prog != NULL) {
- bpf_prog->len = statbuf.st_size / sizeof(struct sock_filter);
- bpf_prog->filter = NULL;
+ if (bpf_prog == NULL) {
+ printk(KERN_ERR "Failed to allocate bpf prog buffer");
+ return NULL;
}
+ bpf_prog->len = statbuf.st_size / sizeof(struct sock_filter);
+ bpf_prog->filter = NULL;
ffd = os_open_file(filename, of_read(OPENFLAGS()), 0);
if (ffd < 0) {
printk(KERN_ERR "Error %d opening bpf file", -errno);
--
2.17.1
Re: [PATCH] EDAC/mc: call edac_inc_ue_error() before panic
On Thu, Jun 11, 2020 at 1:19 AM Luck, Tony wrote: > > On Wed, Jun 10, 2020 at 02:58:46PM +0800, Zhenzhong Duan wrote: > > By calling edac_inc_ue_error() before panic, we get a correct UE error > > count for core dump analysis. > > Looks accurate, and I'll add the patch to be applied. But I wonder > how big a problem it is. Isn't most of the information deriveable > from the panic message? Thanks for review. Yes, it's totally not a problem. I'm a little too strict here. Zhenzhong
[PATCH] x86/mce: fix a wrong assignment of i_mce.status
The original code is a nop as i_mce.status is or'ed with part of itself,
fix it.
Signed-off-by: Zhenzhong Duan
---
arch/x86/kernel/cpu/mce/inject.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/mce/inject.c b/arch/x86/kernel/cpu/mce/inject.c
index 3413b41..dc28a61 100644
--- a/arch/x86/kernel/cpu/mce/inject.c
+++ b/arch/x86/kernel/cpu/mce/inject.c
@@ -511,7 +511,7 @@ static void do_inject(void)
*/
if (inj_type == DFR_INT_INJ) {
i_mce.status |= MCI_STATUS_DEFERRED;
- i_mce.status |= (i_mce.status & ~MCI_STATUS_UC);
+ i_mce.status &= ~MCI_STATUS_UC;
}
/*
--
1.8.3.1
Re: possible deadlock in send_sigio
On 4/4/20 1:55 AM, syzbot wrote:
Hello,
syzbot found the following crash on:
HEAD commit:bef7b2a7 Merge tag 'devicetree-for-5.7' of git://git.kerne..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15f39c5de0
kernel config: https://syzkaller.appspot.com/x/.config?x=91b674b8f0368e69
dashboard link: https://syzkaller.appspot.com/bug?extid=a9fb1457d720a55d6dc5
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1454c3b7e0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12a22ac7e0
The bug was bisected to:
commit 7bc3e6e55acf065500a24621f3b313e7e5998acf
Author: Eric W. Biederman
Date: Thu Feb 20 00:22:26 2020 +
proc: Use a list of inodes to flush from proc
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=165c4acde0
final crash:https://syzkaller.appspot.com/x/report.txt?x=155c4acde0
console output: https://syzkaller.appspot.com/x/log.txt?x=115c4acde0
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+a9fb1457d720a55d6...@syzkaller.appspotmail.com
Fixes: 7bc3e6e55acf ("proc: Use a list of inodes to flush from proc")
WARNING: possible irq lock inversion dependency detected
5.6.0-syzkaller #0 Not tainted
ksoftirqd/0/9 just changed the state of lock:
898090d8 (tasklist_lock){.+.?}-{2:2}, at: send_sigio+0xa9/0x340
fs/fcntl.c:800
but this lock took another, SOFTIRQ-unsafe lock in the past:
(>wait_pidfd){+.+.}-{2:2}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0CPU1
lock(>wait_pidfd);
local_irq_disable();
lock(tasklist_lock);
lock(>wait_pidfd);
lock(tasklist_lock);
*** DEADLOCK ***
That is a false positive. The qrwlock has the special property that it
becomes unfair (for read lock) at interrupt context. So unless it is
taking a write lock in the interrupt context, it won't go into deadlock.
The current lockdep code does not capture the full semantics of qrwlock
leading to this false positive.
Cheers,
Longman
Re: [PATCH v2] ovl: provide real_file() and overlayfs get_unmapped_area()
On 6/10/20 7:17 PM, Al Viro wrote: > On Wed, Jun 10, 2020 at 06:36:16PM -0700, Matthew Wilcox wrote: > >> while (file->f_mode & FMODE_OVL_UPPER) >> file = file->private_data; >> return file; >> >> Or are you proposing that overlayfs copy FMODE_HUGEPAGES from the >> underlying fs to the overlaying fs? > > The latter - that way nobody outside of overlayfs needs to know what > its ->private_data points to, for one thing. And it's cheaper that > way, obviously. > Thanks Al and Matthew! I knew adding a file op for this was overkill and was looking for other suggestions. -- Mike Kravetz
Re: [PATCH] vfs: don't unnecessarily clone write access for writable fds
On Wed, Jun 10, 2020 at 06:49:45PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> There's no need for mnt_want_write_file() to clone a write reference to
> the mount when the file is already open for writing, provided that
> mnt_drop_write_file() is changed to conditionally drop the reference.
>
> We seem to have ended up in the current situation because
> mnt_want_write_file() used to be paired with mnt_drop_write(), due to
> mnt_drop_write_file() not having been added yet. So originally
> mnt_want_write_file() did have to always take a reference.
>
> But later mnt_drop_write_file() was added, and all callers of
> mnt_want_write_file() were paired with it. This makes the compatibility
> between mnt_want_write_file() and mnt_drop_write() no longer necessary.
>
> Therefore, make __mnt_want_write_file() and __mnt_drop_write_file() be
> no-ops on files already open for writing. This removes the only caller
> of mnt_clone_write(), so remove that too.
>
> Signed-off-by: Eric Biggers
> ---
> fs/namespace.c| 43 ++-
> include/linux/mount.h | 1 -
> 2 files changed, 10 insertions(+), 34 deletions(-)
>
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 7cd64240916573..7e78c7ae4ab34d 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -359,51 +359,27 @@ int mnt_want_write(struct vfsmount *m)
> }
> EXPORT_SYMBOL_GPL(mnt_want_write);
>
> -/**
> - * mnt_clone_write - get write access to a mount
> - * @mnt: the mount on which to take a write
> - *
> - * This is effectively like mnt_want_write, except
> - * it must only be used to take an extra write reference
> - * on a mountpoint that we already know has a write reference
> - * on it. This allows some optimisation.
> - *
> - * After finished, mnt_drop_write must be called as usual to
> - * drop the reference.
> - */
> -int mnt_clone_write(struct vfsmount *mnt)
> -{
> - /* superblock may be r/o */
> - if (__mnt_is_readonly(mnt))
> - return -EROFS;
> - preempt_disable();
> - mnt_inc_writers(real_mount(mnt));
> - preempt_enable();
> - return 0;
> -}
> -EXPORT_SYMBOL_GPL(mnt_clone_write);
Sorry, I think I missed something -- the __mnt_is_readonly() check should be
kept because there are cases where SB_RDONLY can be set when there are writable
file descriptors. For example, ext4 with errors=remount-ro.
Interestingly though, sys_write() skips that check because it uses
file_start_write() which only does the freeze protection.
- Eric
Re: [RFC PATCH] fix use after free in xlog_wait()
On Thu, Jun 11, 2020 at 09:39:52AM +0800, Yu Kuai wrote: > I recently got UAF by running generic/019 in qemu: > > == > BUG: KASAN: use-after-free in __lock_acquire+0x4508/0x68c0 > Read of size 8 at addr 88811327f080 by task fio/11147 >remove_wait_queue+0x1d/0x180 >xfs_log_commit_cil+0x1d9e/0x2a50 >__xfs_trans_commit+0x292/0xec0 Ok, so this is waking up from a the CIL context overrunning the hard size limit >Freed by task 6826: >save_stack+0x1b/0x40 >__kasan_slab_free+0x12c/0x170 >kfree+0xd6/0x300 >kvfree+0x42/0x50 >xlog_cil_committed+0xa9c/0xf30 >xlog_cil_push_work+0xa8c/0x1250 >process_one_work+0xa3e/0x17a0 >worker_thread+0x8e2/0x1050 >kthread+0x355/0x470 >ret_from_fork+0x22/0x30 H. The CIL push work freed the context which means somethign went wrong somewhere - we must be in CIL commit error path here... /me checks generic/019 Oh, it's a repeated shutdown test. Right, so we're getting a shutdown in the middle of a CIL push when the CIL is hard throttling callers and the CIL context gets freed before the throttled tasks can be woken. Gotcha. Yup, that's a real issue, thanks for reporting it! > I think the reason is that when 'ctx' is freed in xlog_cil_committed(), > a previous call to xlog_wait(>xc_ctx->push_wait, ...) hasn't finished > yet. Thus when remove_wait_queue() is called, UAF will be triggered > since 'ctx' was freed: > > thread1 thread2 thread3 > > __xfs_trans_commit > xfs_log_commit_cil > xlog_wait >schedule > xlog_cil_push_work >wake_up_all > xlog_cil_committed >kmem_free >remove_wait_queue > spin_lock_irqsave --> UAF Actually, it's a lot simpler: thread1 thread2 __xfs_trans_commit xfs_log_commit_cil xlog_wait schedule xlog_cil_push_work wake_up_all xlog_cil_committed kmem_free remove_wait_queue spin_lock_irqsave --> UAF > Instead, make sure waitqueue_active(>push_wait) return false before > freeing 'ctx'. > > Signed-off-by: Yu Kuai > --- > fs/xfs/xfs_log_cil.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/xfs/xfs_log_cil.c b/fs/xfs/xfs_log_cil.c > index b43f0e8f43f2..59b21485b0fc 100644 > --- a/fs/xfs/xfs_log_cil.c > +++ b/fs/xfs/xfs_log_cil.c > @@ -607,7 +607,7 @@ xlog_cil_committed( > > if (!list_empty(>busy_extents)) > xlog_discard_busy_extents(mp, ctx); > - else > + else if (!waitqueue_active(>push_wait)) > kmem_free(ctx); That will just leak the memory instead, which is no better. Let me go write a patch to fix this. Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [RFC PATCH v4 08/10] i40e/vf_migration: VF live migration - pass-through VF first
On 2020/6/11 8:23, Yan Zhao wrote:
> On Wed, Jun 10, 2020 at 04:59:43PM +0800, Xiang Zheng wrote:
>> Hi Yan,
>>
>> few nits below...
>>
>> On 2020/5/18 10:53, Yan Zhao wrote:
>>> This driver intercepts all device operations as long as it's probed
>>> successfully by vfio-pci driver.
>>>
>>> It will process regions and irqs of its interest and then forward
>>> operations to default handlers exported from vfio pci if it wishes to.
>>>
>>> In this patch, this driver does nothing but pass through VFs to guest
>>> by calling to exported handlers from driver vfio-pci.
>>>
>>> Cc: Shaopeng He
>>>
>>> Signed-off-by: Yan Zhao
>>> ---
>>> drivers/net/ethernet/intel/Kconfig| 10 ++
>>> drivers/net/ethernet/intel/i40e/Makefile | 2 +
>>> .../ethernet/intel/i40e/i40e_vf_migration.c | 165 ++
>>> .../ethernet/intel/i40e/i40e_vf_migration.h | 59 +++
>>> 4 files changed, 236 insertions(+)
>>> create mode 100644 drivers/net/ethernet/intel/i40e/i40e_vf_migration.c
>>> create mode 100644 drivers/net/ethernet/intel/i40e/i40e_vf_migration.h
>>>
>>> diff --git a/drivers/net/ethernet/intel/Kconfig
>>> b/drivers/net/ethernet/intel/Kconfig
>>> index ad34e4335df2..31780d9a59f1 100644
>>> --- a/drivers/net/ethernet/intel/Kconfig
>>> +++ b/drivers/net/ethernet/intel/Kconfig
>>> @@ -264,6 +264,16 @@ config I40E_DCB
>>>
>>> If unsure, say N.
>>>
[...]
>>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_vf_migration.h
>>> b/drivers/net/ethernet/intel/i40e/i40e_vf_migration.h
>>> new file mode 100644
>>> index ..696d40601ec3
>>> --- /dev/null
>>> +++ b/drivers/net/ethernet/intel/i40e/i40e_vf_migration.h
>>> @@ -0,0 +1,59 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/* Copyright(c) 2013 - 2019 Intel Corporation. */
>>> +
>>> +#ifndef I40E_MIG_H
>>> +#define I40E_MIG_H
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#include "i40e.h"
>>> +#include "i40e_txrx.h"
>>> +
>>> +/* helper macros copied from vfio-pci */
>>> +#define VFIO_PCI_OFFSET_SHIFT 40
>>> +#define VFIO_PCI_OFFSET_TO_INDEX(off) ((off) >> VFIO_PCI_OFFSET_SHIFT)
>>> +#define VFIO_PCI_INDEX_TO_OFFSET(index)((u64)(index) <<
>>> VFIO_PCI_OFFSET_SHIFT)
>>> +#define VFIO_PCI_OFFSET_MASK(((u64)(1) << VFIO_PCI_OFFSET_SHIFT) - 1)
>>> +
>>> +/* Single Root I/O Virtualization */
>>> +struct pci_sriov {
>>> + int pos;/* Capability position */
>>> + int nres; /* Number of resources */
>>> + u32 cap;/* SR-IOV Capabilities */
>>> + u16 ctrl; /* SR-IOV Control */
>>> + u16 total_VFs; /* Total VFs associated with the PF */
>>> + u16 initial_VFs;/* Initial VFs associated with the PF */
>>> + u16 num_VFs;/* Number of VFs available */
>>> + u16 offset; /* First VF Routing ID offset */
>>> + u16 stride; /* Following VF stride */
>>> + u16 vf_device; /* VF device ID */
>>> + u32 pgsz; /* Page size for BAR alignment */
>>> + u8 link; /* Function Dependency Link */
>>> + u8 max_VF_buses; /* Max buses consumed by VFs */
>>> + u16 driver_max_VFs; /* Max num VFs driver supports */
>>> + struct pci_dev *dev; /* Lowest numbered PF */
>>> + struct pci_dev *self; /* This PF */
>>> + u32 cfg_size; /* VF config space size */
>>> + u32 class; /* VF device */
>>> + u8 hdr_type; /* VF header type */
>>> + u16 subsystem_vendor; /* VF subsystem vendor */
>>> + u16 subsystem_device; /* VF subsystem device */
>>>
>>> + resource_size_t barsz[PCI_SRIOV_NUM_BARS]; /* VF BAR size */
>>> + booldrivers_autoprobe; /* Auto probing of VFs by driver */
>>> +};
>>> +
>>
>> Can "struct pci_sriov" be extracted for common use? This should not be
>> exclusive
>> for "i40e_vf migration support".
>>
> the definition of this structure is actually in driver/pci/pci.h.
> maybe removing the copy here and use below include is better?
> #include "../../../../pci/pci.h"
>
How about moving the definition from driver/pci/pci.h into include/linux/pci.h?
So
we can just include "linux/pci.h" and removing the copy here.
--
Thanks,
Xiang
Re: [PATCH v7 7/7] mm/madvise: allow KSM hints for remote API
On Mon, Mar 2, 2020 at 8:36 PM Minchan Kim wrote: > From: Oleksandr Natalenko > > It all began with the fact that KSM works only on memory that is marked > by madvise(). And the only way to get around that is to either: [...] > To overcome this restriction, lets employ a new remote madvise API. This > can be used by some small userspace helper daemon that will do auto-KSM > job for us. > > I think of two major consumers of remote KSM hints: [...] > * heavy applications, that can be run in multiple instances, not > limited to opensource ones like Firefox, but also those that cannot be > modified since they are binary-only and, maybe, statically linked. Just as a note, since you're mentioning Firefox as a usecase: Memory deduplication between browser renderers creates new side channels and is a questionable idea from a security standpoint. Memory deduplication is (mostly) fine if either all involved processes are trusted or no involved processes contain secrets, but browsers usually run tons of untrusted code while at the same time containing lots of valuable secrets.
Re: [kernfs] ea7c5fc39a: stress-ng.stream.ops_per_sec 11827.2% improvement
On 6/10/20 7:06 PM, kernel test robot wrote: On Sun, Jun 07, 2020 at 09:13:08AM +0800, Ian Kent wrote: It seems the result of stress-ng is inaccurate if test time too short, we'll increase the test time to avoid unreasonable results, sorry for the inconvenience. Thank you for your response! I was examining the 25 tests in the 'cpu-cache' class and had nothing but head scratching so far on what could be having that effect. Rick
Re: [kmemleak] b751c52bb5: BUG:kernel_hang_in_boot_stage
On 6/10/20 6:56 PM, Catalin Marinas wrote:
On Wed, Jun 10, 2020 at 03:51:56PM +0800, kernel test robot wrote:
FYI, we noticed the following commit (built with gcc-7):
commit: b751c52bb587ae66f773b15204ef7a147467f4c7 ("kmemleak: increase
DEBUG_KMEMLEAK_EARLY_LOG_SIZE default to 16K")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 8G
[...]
BUG: kernel hang in boot stage
To reproduce:
# build kernel
cd linux
cp config-5.3.0-11789-gb751c52bb587a .config
make HOSTCC=gcc-7 CC=gcc-7 ARCH=i386 olddefconfig prepare
modules_prepare bzImage
I've never tried kmemleak on i386.
Anyway, I'm not sure what caused the hang (or whether it's a hang at
all) but I suspect prior to the above commit, kmemleak probably just
disabled itself (early log buffer exceeded).
So the bug may have been
there already,
I think so
only that kmemleak started working and tripped over it
when the log buffer increased.
Is there a chance that the kernel got much slower with kmemleak enabled
and the test scripts timed out?
Does this problem still exist with the latest mainline?
Yes, that's true.
Thanks
Zhijian (0Day CI team)
Thanks.
Re: [PATCH 1/2] integrity: Add errno field in audit message
On Wed, Jun 10, 2020 at 9:58 PM Lakshmi Ramasubramanian
wrote:
> On 6/10/20 6:45 PM, Paul Moore wrote:
>
> Hi Paul,
>
> > I'm sorry I didn't get a chance to mention this before you posted this
> > patch, but for the past several years we have been sticking with a
> > policy of only adding new fields to the end of existing records;
> > please adjust this patch accordingly. Otherwise, this looks fine to
> > me.
> >
> >> audit_log_untrustedstring(ab, get_task_comm(name, current));
> >> if (fname) {
> >> audit_log_format(ab, " name=");
> >> --
>
> Steve mentioned that since this new field "errno" is not a searchable
> entry, it can be added anywhere in the audit log message.
Steve and I have a different opinion on this issue. I won't rehash
the long argument or drag you into it, but I will just say that the
*kernel* has had a policy of only adding fields to the end of existing
records unless under extreme cases (this is not an extreme case).
> But I have no problem moving this to the end of the audit record.
Great, please do that. Thank you.
--
paul moore
www.paul-moore.com
Re: [PATCH v2] ovl: provide real_file() and overlayfs get_unmapped_area()
On Wed, Jun 10, 2020 at 06:36:16PM -0700, Matthew Wilcox wrote: > while (file->f_mode & FMODE_OVL_UPPER) > file = file->private_data; > return file; > > Or are you proposing that overlayfs copy FMODE_HUGEPAGES from the > underlying fs to the overlaying fs? The latter - that way nobody outside of overlayfs needs to know what its ->private_data points to, for one thing. And it's cheaper that way, obviously.
[PATCH v2 1/2] dt-bindings: usb: Add USB PHY support for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add the dt-schema to support USB PHY on Intel LGM SoC
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/usb/intel,lgm-usb-phy.yaml | 53 ++
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/intel,lgm-usb-phy.yaml
diff --git a/Documentation/devicetree/bindings/usb/intel,lgm-usb-phy.yaml
b/Documentation/devicetree/bindings/usb/intel,lgm-usb-phy.yaml
new file mode 100644
index ..0fc76cd23774
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/intel,lgm-usb-phy.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/intel,lgm-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM USB PHY Device Tree Bindings
+
+maintainers:
+ - Vadivel Murugan Ramuthevar
+
+properties:
+ compatible:
+const: intel,lgm-usb-phy
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ resets:
+items:
+ - description: USB PHY and Host controller reset
+ - description: APB BUS reset
+ - description: General Hardware reset
+
+ reset-names:
+items:
+ - const: phy
+ - const: apb
+ - const: phy31
+
+required:
+ - compatible
+ - clocks
+ - reg
+ - resets
+ - reset-names
+
+additionalProperties: false
+
+examples:
+ - |
+usb_phy: usb_phy@e7e0 {
+compatible = "intel,lgm-usb-phy";
+reg = <0xe7e0 0x1>;
+clocks = < 153>;
+resets = < 0x70 0x24>,
+ < 0x70 0x26>,
+ < 0x70 0x28>;
+reset-names = "phy", "apb", "phy31";
+};
--
2.11.0
[PATCH v2 2/2] usb: phy: Add USB3 PHY support for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add support for USB PHY on Intel LGM SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/usb/phy/Kconfig | 11 ++
drivers/usb/phy/Makefile | 1 +
drivers/usb/phy/phy-lgm-usb.c | 280 ++
3 files changed, 292 insertions(+)
create mode 100644 drivers/usb/phy/phy-lgm-usb.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 4b3fa78995cf..95f2e737d663 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -192,4 +192,15 @@ config JZ4770_PHY
This driver provides PHY support for the USB controller found
on the JZ4770 SoC from Ingenic.
+config USB_LGM_PHY
+ tristate "INTEL Lightning Mountain USB PHY Driver"
+ depends on USB_SUPPORT
+ select USB_PHY
+ select REGULATOR
+ select REGULATOR_FIXED_VOLTAGE
+ help
+ Enable this to support Intel DWC3 PHY USB phy. This driver provides
+ interface to interact with USB GEN-II and USB 3.x PHY that is part
+ of the Intel network SOC.
+
endmenu
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index b352bdbe8712..ef5345164e10 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_USB_ULPI)+= phy-ulpi.o
obj-$(CONFIG_USB_ULPI_VIEWPORT)+= phy-ulpi-viewport.o
obj-$(CONFIG_KEYSTONE_USB_PHY) += phy-keystone.o
obj-$(CONFIG_JZ4770_PHY) += phy-jz4770.o
+obj-$(CONFIG_USB_LGM_PHY) += phy-lgm-usb.o
diff --git a/drivers/usb/phy/phy-lgm-usb.c b/drivers/usb/phy/phy-lgm-usb.c
new file mode 100644
index ..eb415533bc66
--- /dev/null
+++ b/drivers/usb/phy/phy-lgm-usb.c
@@ -0,0 +1,280 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel LGM USB PHY driver
+ *
+ * Copyright (C) 2020 Intel Corporation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CTRL1_OFFSET 0x14
+#define SRAM_EXT_LD_DONE BIT(25)
+#define SRAM_INIT_DONE BIT(26)
+
+#define TCPC_OFFSET0x1014
+#define TCPC_MUX_CTL GENMASK(1, 0)
+#define MUX_NC 0
+#define MUX_USB1
+#define MUX_DP 2
+#define MUX_USBDP 3
+#define TCPC_FLIPPED BIT(2)
+#define TCPC_LOW_POWER_EN BIT(3)
+#define TCPC_VALID BIT(4)
+#define TCPC_DISCONN \
+ (TCPC_VALID | FIELD_PREP(TCPC_MUX_CTL, MUX_NC) | TCPC_LOW_POWER_EN)
+
+static const char *const PHY_RESETS[] = { "phy31", "phy", };
+static const char *const CTL_RESETS[] = { "apb", "ctrl", };
+
+struct tca_apb {
+ struct reset_control *resets[ARRAY_SIZE(PHY_RESETS)];
+ struct regulator *vbus;
+ struct work_struct wk;
+ struct usb_phy phy;
+
+ bool phy_initialized;
+ bool connected;
+};
+
+static int get_flipped(struct tca_apb *ta, bool *flipped)
+{
+ union extcon_property_value property;
+ int ret;
+
+ ret = extcon_get_property(ta->phy.edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_TYPEC_POLARITY, );
+ if (ret) {
+ dev_err(ta->phy.dev, "no polarity property from extcon\n");
+ return false;
+ }
+
+ *flipped = property.intval;
+
+ return *flipped;
+}
+
+static int phy_init(struct usb_phy *phy)
+{
+ struct tca_apb *ta = container_of(phy, struct tca_apb, phy);
+ void __iomem *ctrl1 = phy->io_priv + CTRL1_OFFSET;
+ int val, ret, i;
+
+ if (ta->phy_initialized)
+ return 0;
+
+ for (i = 0; i < ARRAY_SIZE(PHY_RESETS); i++)
+ reset_control_deassert(ta->resets[i]);
+
+ ret = readl_poll_timeout(ctrl1, val, val & SRAM_INIT_DONE,
+10, 10 * 1000);
+ if (ret) {
+ dev_err(ta->phy.dev, "SRAM init failed, 0x%x\n", val);
+ return ret;
+ }
+
+ writel(readl(ctrl1) | SRAM_EXT_LD_DONE, ctrl1);
+
+ ta->phy_initialized = true;
+ if (!ta->phy.edev)
+ return phy->set_vbus(phy, true);
+
+ schedule_work(>wk);
+
+ return 0;
+}
+
+static void phy_shutdown(struct usb_phy *phy)
+{
+ struct tca_apb *ta = container_of(phy, struct tca_apb, phy);
+ int i;
+
+ if (!ta->phy_initialized)
+ return;
+
+ ta->phy_initialized = false;
+ flush_work(>wk);
+ ta->phy.set_vbus(>phy, false);
+ if (ta->connected) {
+ ta->connected = false;
+ writel(TCPC_DISCONN, ta->phy.io_priv + TCPC_OFFSET);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(PHY_RESETS); i++)
+ reset_control_assert(ta->resets[i]);
+}
+
+static int phy_set_vbus(struct usb_phy *phy, int on)
+{
+ struct tca_apb *ta = container_of(phy, struct tca_apb, phy);
+ int ret = 0;
+
+ if (on) {
+
[PATCH v2 0/2] usb : phy: Add USB PHY support on Intel LGM SoC
The USB PHY provides the optimized for low power dissipation while active, idle, or on standby. Requires minimal external components, a single resistor, for best operation. Supports 10/5-Gbps high-speed data transmission rates through 3-m USB 3.x cable --- v2: - Address Phillip's review comments - replace devm_reset_control_get() by devm_reset_control_get_exclusive() - re-design the assert and deassert fucntion calls as per review comments - address kbuild bot warnings - add the comments v1: - initial version --- dt-bindings: usb: Add USB PHY support for Intel LGM SoC v2: - No Change v1: - initial version Ramuthevar Vadivel Murugan (2): dt-bindings: usb: Add USB PHY support for Intel LGM SoC usb: phy: Add USB3 PHY support for Intel LGM SoC .../devicetree/bindings/usb/intel,lgm-usb-phy.yaml | 53 drivers/usb/phy/Kconfig| 11 + drivers/usb/phy/Makefile | 1 + drivers/usb/phy/phy-lgm-usb.c | 280 + 4 files changed, 345 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/intel,lgm-usb-phy.yaml create mode 100644 drivers/usb/phy/phy-lgm-usb.c -- 2.11.0
Re: [PATCH v2 1/1] selinux: fix double free
On Wed, Jun 10, 2020 at 5:57 PM wrote:
> From: Tom Rix
>
> Clang's static analysis tool reports these double free memory errors.
>
> security/selinux/ss/services.c:2987:4: warning: Attempt to free released
> memory [unix.Malloc]
> kfree(bnames[i]);
> ^~~~
> security/selinux/ss/services.c:2990:2: warning: Attempt to free released
> memory [unix.Malloc]
> kfree(bvalues);
> ^~
>
> So improve the security_get_bools error handling by freeing these variables
> and setting their return pointers to NULL and the return len to 0
>
> Signed-off-by: Tom Rix
> ---
> security/selinux/ss/services.c | 4
> 1 file changed, 4 insertions(+)
Thanks Tom for the patch and Stephen for the review.
I've marked this for stable and merged it into selinux/stable-5.8.
Considering we are just a few days away from the close of the merge
window and -rc1, I'll probably hold off until next to send this up to
Linus.
> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> index 313919bd42f8..ef0afd878bfc 100644
> --- a/security/selinux/ss/services.c
> +++ b/security/selinux/ss/services.c
> @@ -2888,8 +2888,12 @@ int security_get_bools(struct selinux_state *state,
> if (*names) {
> for (i = 0; i < *len; i++)
> kfree((*names)[i]);
> + kfree(*names);
> }
> kfree(*values);
> + *len = 0;
> + *names = NULL;
> + *values = NULL;
> goto out;
> }
>
> --
> 2.18.1
--
paul moore
www.paul-moore.com
Re: linux-next: manual merge of the scsi-mkp tree with Linus' tree
Hi all,
On Wed, 10 Jun 2020 12:17:07 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the scsi-mkp tree got a conflict in:
>
> drivers/scsi/sr.c
>
> between commit:
>
> a711d91cd97e ("block: add a cdrom_device_info pointer to struct gendisk")
>
> from Linus' tree and commit:
>
> 6555781b3fde ("scsi: sr: Fix sr_probe() missing deallocate of device minor")
>
> from the scsi-mkp tree.
>
> diff --cc drivers/scsi/sr.c
> index 4dcd735ea49e,b9cff27e2c81..
> --- a/drivers/scsi/sr.c
> +++ b/drivers/scsi/sr.c
> @@@ -790,9 -790,10 +790,9 @@@ static int sr_probe(struct device *dev
> set_capacity(disk, cd->capacity);
> disk->private_data = >driver;
> disk->queue = sdev->request_queue;
> -cd->cdi.disk = disk;
>
> -if (register_cdrom(>cdi))
> +if (register_cdrom(disk, >cdi))
> - goto fail_put;
> + goto fail_minor;
>
> /*
>* Initialize block layer runtime PM stuffs before the
This is now a conflict between the scsi tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpT1UpbFeXwh.pgp
Description: OpenPGP digital signature
[PATCH] ARM: dts: rockchip: Add marvell BT irq config
Veyron Jaq and Mighty both use the Marvel 8897 WiFi+BT chip. Add wakeup
and pinctrl block to devicetree so the btmrvl driver can correctly
configure the wakeup interrupt.
Signed-off-by: Abhishek Pandit-Subedi
Reviewed-by: Reviewed-by: Douglas Anderson
---
The Veyron Mighty Chromebook (rk3288 based board) is missing the wake
configuration for Bluetooth. Without this change, the wake irq was not
configurable and wake on Bluetooth was broken.
I verified this change with additional changes in the Bluetooth driver
(the series is at https://patchwork.kernel.org/cover/11599101/). The
driver changes are not necessary for this dts change and shouldn't block
it.
arch/arm/boot/dts/rk3288-veyron-jaq.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
index 171ba6185b6d39..976c0c17a71199 100644
--- a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
@@ -51,6 +51,21 @@ {
_bus4>;
};
+ {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ btmrvl: btmrvl@2 {
+ compatible = "marvell,sd8897-bt";
+ reg = <2>;
+ interrupt-parent = <>;
+ interrupts = ;
+ marvell,wakeup-pin = /bits/ 16 <13>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_host_wake_l>;
+ };
+};
+
_5v {
enable-active-high;
gpio = < RK_PC5 GPIO_ACTIVE_HIGH>;
--
2.27.0.278.ge193c7cf3a9-goog
Re: [kernfs] ea7c5fc39a: stress-ng.stream.ops_per_sec 11827.2% improvement
On Sun, Jun 07, 2020 at 09:13:08AM +0800, Ian Kent wrote:
> On Sat, 2020-06-06 at 20:18 +0200, Greg Kroah-Hartman wrote:
> > On Sat, Jun 06, 2020 at 11:52:16PM +0800, kernel test robot wrote:
> > > Greeting,
> > >
> > > FYI, we noticed a 11827.2% improvement of stress-
> > > ng.stream.ops_per_sec due to commit:
> > >
> > >
> > > commit: ea7c5fc39ab005b501e0c7666c29db36321e4f74 ("[PATCH 1/4]
> > > kernfs: switch kernfs to use an rwsem")
> > > url:
> > > https://github.com/0day-ci/linux/commits/Ian-Kent/kernfs-proposed-locking-and-concurrency-improvement/20200525-134849
> > >
> >
> > Seriously? That's a huge performance increase, and one that feels
> > really odd. Why would a stress-ng test be touching sysfs?
>
> That is unusually high even if there's a lot of sysfs or kernfs
> activity and that patch shouldn't improve VFS path walk contention
> very much even if it is present.
>
> Maybe I've missed something, and the information provided doesn't
> seem to be quite enough to even make a start on it.
>
> That's going to need some analysis which, for my part, will need to
> wait probably until around rc1 time frame to allow me to get through
> the push down stack (reactive, postponed due to other priorities) of
> jobs I have in order to get back to the fifo queue (longer term tasks,
> of which this is one) list of jobs I need to do as well, ;)
>
> Please, kernel test robot, more information about this test and what
> it's doing.
>
Hi Ian,
We increased the timeout of stress-ng from 1s to 32s, and there's only
3% improvement of stress-ng.stream.ops_per_sec:
fefcfc968723caf9 ea7c5fc39ab005b501e0c7666c testcase/testparams/testbox
-- ---
%stddev change %stddev
\ |\
10686 3% 11037
stress-ng/cpu-cache-performance-1HDD-100%-32s-ucode=0x52c/lkp-csl-2sp5
10686 3% 11037GEO-MEAN
stress-ng.stream.ops_per_sec
It seems the result of stress-ng is inaccurate if test time too
short, we'll increase the test time to avoid unreasonable results,
sorry for the inconvenience.
Best Regards,
Rong Chen
Re: [f2fs-dev] [PATCH] f2fs: add F2FS_IOC_SEC_TRIM_FILE ioctl
Ok, I got it. Thanks for quick response~ :)
2020년 6월 11일 (목) 오전 10:56, Eric Biggers 님이 작성:
>
> On Thu, Jun 11, 2020 at 09:23:23AM +0900, Daeho Jeong wrote:
> > Yes, I saw the implementation in vfs_write().
> > But if we use mnt_want_write_file() here, it'll call mnt_clone_write()
> > internally if the file is already open in write mode.
> > Don't you think the below thing is needed? We can increase the counter
> > each of them, open and ioctl, like other filesystems such as ext4.
> >
> > int mnt_clone_write(struct vfsmount *mnt)
> > {
> > /* superblock may be r/o */
> > if (__mnt_is_readonly(mnt))
> > return -EROFS;
> > preempt_disable();
> > mnt_inc_writers(real_mount(mnt));
> > preempt_enable();
> > return 0;
> > }
>
> No, this seems to be left over from when mnt_want_write_file() was paired with
> mnt_drop_write() instead of mnt_drop_write_file(). I sent a patch to remove
> it:
> https://lkml.kernel.org/r/20200611014945.237210-1-ebigg...@kernel.org
>
> - Eric
Re: [PATCH 1/2] integrity: Add errno field in audit message
On 6/10/20 6:45 PM, Paul Moore wrote:
Hi Paul,
I'm sorry I didn't get a chance to mention this before you posted this
patch, but for the past several years we have been sticking with a
policy of only adding new fields to the end of existing records;
please adjust this patch accordingly. Otherwise, this looks fine to
me.
audit_log_untrustedstring(ab, get_task_comm(name, current));
if (fname) {
audit_log_format(ab, " name=");
--
Steve mentioned that since this new field "errno" is not a searchable
entry, it can be added anywhere in the audit log message.
But I have no problem moving this to the end of the audit record.
thanks,
-lakshmi
[tip:WIP.fixes] BUILD SUCCESS 0acd9a0ded80c986ccc9588ba2703436769ead74
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.fixes branch HEAD: 0acd9a0ded80c986ccc9588ba2703436769ead74 Revert "mm/vmalloc: modify struct vmap_area to reduce its size" elapsed time: 1130m configs tested: 172 configs skipped: 15 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig m68k amcore_defconfig mips rbtx49xx_defconfig um defconfig sh magicpanelr2_defconfig powerpc ep88xc_defconfig shecovec24-romimage_defconfig sparc64 allmodconfig powerpc mpc885_ads_defconfig mips xway_defconfig arm cns3420vb_defconfig m68k sun3x_defconfig sparc sparc32_defconfig riscv rv32_defconfig arm h3600_defconfig powerpcmvme5100_defconfig openrisc simple_smp_defconfig sparcallyesconfig sh se7705_defconfig mips decstation_defconfig csky allyesconfig arm zx_defconfig mipsnlm_xlr_defconfig sh shx3_defconfig c6xevmc6678_defconfig arc nsimosci_hs_smp_defconfig armmvebu_v5_defconfig arm iop32x_defconfig armmps2_defconfig openrisc allyesconfig nios2 defconfig openriscdefconfig sh se7619_defconfig sh kfr2r09-romimage_defconfig arm moxart_defconfig arc haps_hs_defconfig m68kmac_defconfig armoxnas_v6_defconfig armvt8500_v6_v7_defconfig mips tb0219_defconfig mips malta_defconfig arc axs101_defconfig sh se7724_defconfig arm aspeed_g5_defconfig armdove_defconfig xtensa alldefconfig arm shannon_defconfig umallnoconfig arm socfpga_defconfig arc defconfig sh sh7724_generic_defconfig powerpcamigaone_defconfig arcnsim_700_defconfig alpha defconfig arm exynos_defconfig archsdk_defconfig m68km5272c3_defconfig m68kstmark2_defconfig armqcom_defconfig sh espt_defconfig powerpc allmodconfig powerpc mpc512x_defconfig i386 allnoconfig arm davinci_all_defconfig mips maltasmvp_eva_defconfig armxcep_defconfig arm mv78xx0_defconfig c6xevmc6457_defconfig m68kmvme16x_defconfig s390 allmodconfig ia64 gensparse_defconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2allyesconfig c6x allyesconfig c6x allnoconfig nds32 defconfig nds32 allnoconfig cskydefconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa
Re: [f2fs-dev] [PATCH] f2fs: add F2FS_IOC_SEC_TRIM_FILE ioctl
On Thu, Jun 11, 2020 at 09:23:23AM +0900, Daeho Jeong wrote:
> Yes, I saw the implementation in vfs_write().
> But if we use mnt_want_write_file() here, it'll call mnt_clone_write()
> internally if the file is already open in write mode.
> Don't you think the below thing is needed? We can increase the counter
> each of them, open and ioctl, like other filesystems such as ext4.
>
> int mnt_clone_write(struct vfsmount *mnt)
> {
> /* superblock may be r/o */
> if (__mnt_is_readonly(mnt))
> return -EROFS;
> preempt_disable();
> mnt_inc_writers(real_mount(mnt));
> preempt_enable();
> return 0;
> }
No, this seems to be left over from when mnt_want_write_file() was paired with
mnt_drop_write() instead of mnt_drop_write_file(). I sent a patch to remove it:
https://lkml.kernel.org/r/20200611014945.237210-1-ebigg...@kernel.org
- Eric
[PATCH 3/3] Bluetooth: btmrvl_sdio: Refactor irq wakeup
Use device_init_wakeup to allow the Bluetooth dev to wake the system
from suspend. Currently, the device can wake the system but no
power/wakeup entry is created in sysfs to allow userspace to disable
wakeup.
Signed-off-by: Abhishek Pandit-Subedi
Reviewed-by: Douglas Anderson
---
drivers/bluetooth/btmrvl_sdio.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index 4c7978cb1786fc..cfb9f9db44a0d9 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -111,6 +111,9 @@ static int btmrvl_sdio_probe_of(struct device *dev,
"Failed to request irq_bt %d (%d)\n",
cfg->irq_bt, ret);
}
+
+ /* Configure wakeup (enabled by default) */
+ device_init_wakeup(dev, true);
disable_irq(cfg->irq_bt);
}
}
@@ -1654,6 +1657,7 @@ static void btmrvl_sdio_remove(struct sdio_func *func)
MODULE_SHUTDOWN_REQ);
btmrvl_sdio_disable_host_int(card);
}
+
BT_DBG("unregister dev");
card->priv->surprise_removed = true;
btmrvl_sdio_unregister_dev(card);
@@ -1690,7 +1694,8 @@ static int btmrvl_sdio_suspend(struct device *dev)
}
/* Enable platform specific wakeup interrupt */
- if (card->plt_wake_cfg && card->plt_wake_cfg->irq_bt >= 0) {
+ if (card->plt_wake_cfg && card->plt_wake_cfg->irq_bt >= 0 &&
+ device_may_wakeup(dev)) {
card->plt_wake_cfg->wake_by_bt = false;
enable_irq(card->plt_wake_cfg->irq_bt);
enable_irq_wake(card->plt_wake_cfg->irq_bt);
@@ -1707,7 +1712,8 @@ static int btmrvl_sdio_suspend(struct device *dev)
BT_ERR("HS not activated, suspend failed!");
/* Disable platform specific wakeup interrupt */
if (card->plt_wake_cfg &&
- card->plt_wake_cfg->irq_bt >= 0) {
+ card->plt_wake_cfg->irq_bt >= 0 &&
+ device_may_wakeup(dev)) {
disable_irq_wake(card->plt_wake_cfg->irq_bt);
disable_irq(card->plt_wake_cfg->irq_bt);
}
@@ -1767,7 +1773,8 @@ static int btmrvl_sdio_resume(struct device *dev)
hci_resume_dev(hcidev);
/* Disable platform specific wakeup interrupt */
- if (card->plt_wake_cfg && card->plt_wake_cfg->irq_bt >= 0) {
+ if (card->plt_wake_cfg && card->plt_wake_cfg->irq_bt >= 0 &&
+ device_may_wakeup(dev)) {
disable_irq_wake(card->plt_wake_cfg->irq_bt);
disable_irq(card->plt_wake_cfg->irq_bt);
if (card->plt_wake_cfg->wake_by_bt)
--
2.27.0.278.ge193c7cf3a9-goog
[PATCH 1/3] Bluetooth: btmrvl_sdio: Set parent dev to hdev
Set the correct parent dev when registering hdev. This allows userspace
tools to find the parent device (for example, to set the power/wakeup
property).
Before this change, the path was /sys/devices/virtual/bluetooth/hci0
and after this change, it looks more like:
/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:2/bluetooth/hci0
Signed-off-by: Abhishek Pandit-Subedi
Reviewed-by: Douglas Anderson
---
drivers/bluetooth/btmrvl_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btmrvl_main.c b/drivers/bluetooth/btmrvl_main.c
index 708ad21683eb31..47e450903af423 100644
--- a/drivers/bluetooth/btmrvl_main.c
+++ b/drivers/bluetooth/btmrvl_main.c
@@ -669,6 +669,7 @@ static int btmrvl_service_main_thread(void *data)
int btmrvl_register_hdev(struct btmrvl_private *priv)
{
struct hci_dev *hdev = NULL;
+ struct btmrvl_sdio_card *card = priv->btmrvl_dev.card;
int ret;
hdev = hci_alloc_dev();
@@ -687,6 +688,7 @@ int btmrvl_register_hdev(struct btmrvl_private *priv)
hdev->send = btmrvl_send_frame;
hdev->setup = btmrvl_setup;
hdev->set_bdaddr = btmrvl_set_bdaddr;
+ SET_HCIDEV_DEV(hdev, >func->dev);
hdev->dev_type = priv->btmrvl_dev.dev_type;
--
2.27.0.278.ge193c7cf3a9-goog
[PATCH 2/3] Bluetooth: btmrvl_sdio: Implement prevent_wake
Use the parent device's power/wakeup to control whether we support
remote wake. If remote wakeup is disabled, Bluetooth will not enable
scanning for incoming connections.
Signed-off-by: Abhishek Pandit-Subedi
Reviewed-by: Douglas Anderson
---
drivers/bluetooth/btmrvl_main.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/bluetooth/btmrvl_main.c b/drivers/bluetooth/btmrvl_main.c
index 47e450903af423..8b9d78ce6bb29e 100644
--- a/drivers/bluetooth/btmrvl_main.c
+++ b/drivers/bluetooth/btmrvl_main.c
@@ -587,6 +587,14 @@ static int btmrvl_set_bdaddr(struct hci_dev *hdev, const
bdaddr_t *bdaddr)
return 0;
}
+static bool btmrvl_prevent_wake(struct hci_dev *hdev)
+{
+ struct btmrvl_private *priv = hci_get_drvdata(hdev);
+ struct btmrvl_sdio_card *card = priv->btmrvl_dev.card;
+
+ return !device_may_wakeup(>func->dev);
+}
+
/*
* This function handles the event generated by firmware, rx data
* received from firmware, and tx data sent from kernel.
@@ -688,6 +696,7 @@ int btmrvl_register_hdev(struct btmrvl_private *priv)
hdev->send = btmrvl_send_frame;
hdev->setup = btmrvl_setup;
hdev->set_bdaddr = btmrvl_set_bdaddr;
+ hdev->prevent_wake = btmrvl_prevent_wake;
SET_HCIDEV_DEV(hdev, >func->dev);
hdev->dev_type = priv->btmrvl_dev.dev_type;
--
2.27.0.278.ge193c7cf3a9-goog
[PATCH] 9p/trans_fd: Fix concurrency del of req_list in p9_fd_cancelled/p9_read_work
p9_read_work and p9_fd_cancelled may be called concurrently.
Before list_del(>rreq->req_list) in p9_read_work is called,
the req->req_list may have been deleted in p9_fd_cancelled.
We can fix it by setting req->status to REQ_STATUS_FLSHD after
list_del(>req_list) in p9_fd_cancelled.
Before list_del(>req_list) in p9_fd_cancelled is called,
the req->req_list may have been deleted in p9_read_work.
We should return when req->status = REQ_STATUS_RCVD which means
we just received a response for oldreq, so we need do nothing
in p9_fd_cancelled.
Fixes: 60ff779c4abb ("9p: client: remove unused code and any reference to
"cancelled" function")
Reported-by: Hulk Robot
Signed-off-by: Wang Hai
---
net/9p/trans_fd.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
index f868cf6fba79..a563699629cb 100644
--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -718,11 +718,18 @@ static int p9_fd_cancelled(struct p9_client *client,
struct p9_req_t *req)
{
p9_debug(P9_DEBUG_TRANS, "client %p req %p\n", client, req);
- /* we haven't received a response for oldreq,
-* remove it from the list.
+ /* If req->status == REQ_STATUS_RCVD, it means we just received a
+* response for oldreq, we need do nothing here. Else, remove it from
+* the list.
*/
spin_lock(>lock);
+ if (req->status == REQ_STATUS_RCVD) {
+ spin_unlock(>lock);
+ return 0;
+ }
+
list_del(>req_list);
+ req->status = REQ_STATUS_FLSHD;
spin_unlock(>lock);
p9_req_put(req);
--
2.17.1
[PATCH 0/3] Bluetooth: btmrvl_sdio: Refactor remote wakeup support
Hi linux-bluetooth, This patch series is refactoring the btmrvl driver to add better support for controlling remote wakeup during suspend. Previously, the hci device was getting created as /sys/devices/virtual/bluetooth/hci0 and there wasn't a way to control wakeup for the device from userspace. This series of changes adds the proper parent for the hci device, allows irq configuration via power/wakeup and properly disables scanning during suspend if wakeup isn't enabled. This was tested on a Veyron Mighty Chromebook running the 4.19 kernel with these patches. It passes both automated and manual suspend+resume tests that make sure wakeup is working properly. Thanks Abhishek Abhishek Pandit-Subedi (3): Bluetooth: btmrvl_sdio: Set parent dev to hdev Bluetooth: btmrvl_sdio: Implement prevent_wake Bluetooth: btmrvl_sdio: Refactor irq wakeup drivers/bluetooth/btmrvl_main.c | 11 +++ drivers/bluetooth/btmrvl_sdio.c | 13 ++--- 2 files changed, 21 insertions(+), 3 deletions(-) -- 2.27.0.278.ge193c7cf3a9-goog
Re: [Question]: about 'cpuinfo_cur_freq' shown in sysfs when the CPU is in idle state
Hi Ionela, Thanks for your reply ! On 2020/6/10 17:40, Ionela Voinescu wrote: > Hi guys, > > Sorry for showing up late to the party, I was on holiday last week. > > On Thursday 04 Jun 2020 at 13:58:22 (+0100), Sudeep Holla wrote: >> On Thu, Jun 04, 2020 at 12:42:06PM +0200, Rafael J. Wysocki wrote: >>> On Thu, Jun 4, 2020 at 6:41 AM Viresh Kumar wrote: On 04-06-20, 09:32, Xiongfeng Wang wrote: > On 2020/6/3 21:39, Rafael J. Wysocki wrote: >> The frequency value obtained by kicking the CPU out of idle >> artificially is bogus, though. You may as well return a random number >> instead. > > Yes, it may return a randowm number as well. > >> >> The frequency of a CPU in an idle state is in fact unknown in the case >> at hand, so returning 0 looks like the cleanest option to me. > > I am not sure about how the user will use 'cpuinfo_cur_freq' in sysfs. If > I > return 0 when the CPU is idle, when I run a light load on the CPU, I will > get a > zero value for 'cpuinfo_cur_freq' when the CPU is idle. When the CPU is > not > idle, I will get a non-zero value. The user may feel odd about > 'cpuinfo_cur_frreq' switching between a zero value and a non-zero value. > They > may hope it can return the frequency when the CPU execute instructions, > namely > in C0 state. I am not so sure about the user will look at > 'cpuinfo_cur_freq'. This is what I was worried about as well. The interface to sysfs needs to be robust. Returning frequency on some readings and 0 on others doesn't look right to me as well. This will break scripts (I am not sure if some scripts are there to look for these values) with the randomness of values returned by it. >>> >>> The only thing the scripts need to do is to skip zeros (or anything >>> less than the minimum hw frequency for that matter) coming from that >>> attribute. >>> On reading values locally from the CPU, I thought about the case where userspace can prevent a CPU going into idle just by reading its frequency from sysfs (and so waste power), but the same can be done by userspace to run arbitrary load on the CPUs. Can we do some sort of caching of the last frequency the CPU was running at before going into idle ? Then we can just check if cpu is idle and so return cached value. >>> >>> That is an option, but it looks like in this case the cpuinfo_cur_freq >>> attribute should not be present at all, as per the documentation. >>> >> >> +1 for dropping the attribute. >> > > I've been experimenting with some code quite recently that uses the > scheduler frequency scale factor to compute this hardware current rate > for CPPC. > > On the scheduler tick, the scale factor is computed in > arch_scale_freq_tick() to give an indication on delivered performance, > using AMUs on arm64 [1] and APERF/MPERF on x86 [2]. Basically, this scale > factor has the cached value of the average delivered performance between > the last two scheduler ticks, on a capacity scale: 0-1024. All that would > be needed is to convert from the scheduler frequency scale to the CPPC > expected performance scale. > > The gist of the code would be: > > delivered_perf = topology_get_freq_scale(cpu); > delivered_perf *= fb_ctrs.reference_perf; > delivered_perf = div64_u64(delivered_perf << SCHED_CAPACITY_SHIFT, > per_cpu(arch_max_freq_scale, cpu)); > > While this solution is not perfect, it would provide the best view of > the hardware "current" rate without the cost of waking up the CPU when > idle, scheduling additional work on the CPU, doing checks on whether > the CPU is idle and/or providing other caching mechanisms. I think it's a good idea. It's just that the value is a average frequency in the last two scheduler ticks, not an instantaneous frequency. What 'cppc_cpufreq_get_rate()' get is also not an instantaneous frequency. It's a average frequency in 2us. I check the interval between two frequency updates on my machine. It's about 10ms. So the frequency will change at least one time in two scheduler ticks if HZ is 1000. I am not sure how people will use 'cpuinfo_cur_freq'. They may not expect a very accurate frequency. How about we return this value when CPU is idle? Or just return 0 in idle is better ? > > Do you think such an implementation could make cpuinfo_cur_freq worth > keeping? > > I'm happy to push the patches for this and discuss the details there. Thanks. I'm happy to see the patches and give some help. Thanks, Xiongfeng > > Thanks, > Ionela. > > > [1] https://lkml.org/lkml/2020/3/5/183 > [2] https://lkml.org/lkml/2020/1/22/1039 > >> -- >> Regards, >> Sudeep > > . >
[PATCH] vfs: don't unnecessarily clone write access for writable fds
From: Eric Biggers
There's no need for mnt_want_write_file() to clone a write reference to
the mount when the file is already open for writing, provided that
mnt_drop_write_file() is changed to conditionally drop the reference.
We seem to have ended up in the current situation because
mnt_want_write_file() used to be paired with mnt_drop_write(), due to
mnt_drop_write_file() not having been added yet. So originally
mnt_want_write_file() did have to always take a reference.
But later mnt_drop_write_file() was added, and all callers of
mnt_want_write_file() were paired with it. This makes the compatibility
between mnt_want_write_file() and mnt_drop_write() no longer necessary.
Therefore, make __mnt_want_write_file() and __mnt_drop_write_file() be
no-ops on files already open for writing. This removes the only caller
of mnt_clone_write(), so remove that too.
Signed-off-by: Eric Biggers
---
fs/namespace.c| 43 ++-
include/linux/mount.h | 1 -
2 files changed, 10 insertions(+), 34 deletions(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index 7cd64240916573..7e78c7ae4ab34d 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -359,51 +359,27 @@ int mnt_want_write(struct vfsmount *m)
}
EXPORT_SYMBOL_GPL(mnt_want_write);
-/**
- * mnt_clone_write - get write access to a mount
- * @mnt: the mount on which to take a write
- *
- * This is effectively like mnt_want_write, except
- * it must only be used to take an extra write reference
- * on a mountpoint that we already know has a write reference
- * on it. This allows some optimisation.
- *
- * After finished, mnt_drop_write must be called as usual to
- * drop the reference.
- */
-int mnt_clone_write(struct vfsmount *mnt)
-{
- /* superblock may be r/o */
- if (__mnt_is_readonly(mnt))
- return -EROFS;
- preempt_disable();
- mnt_inc_writers(real_mount(mnt));
- preempt_enable();
- return 0;
-}
-EXPORT_SYMBOL_GPL(mnt_clone_write);
-
/**
* __mnt_want_write_file - get write access to a file's mount
* @file: the file who's mount on which to take a write
*
- * This is like __mnt_want_write, but it takes a file and can
- * do some optimisations if the file is open for write already
+ * This is like __mnt_want_write, but it does nothing if the file is already
+ * open for writing. This must be paired with __mnt_drop_write_file.
*/
int __mnt_want_write_file(struct file *file)
{
- if (!(file->f_mode & FMODE_WRITER))
- return __mnt_want_write(file->f_path.mnt);
- else
- return mnt_clone_write(file->f_path.mnt);
+ if (file->f_mode & FMODE_WRITER)
+ return 0;
+ return __mnt_want_write(file->f_path.mnt);
}
/**
* mnt_want_write_file - get write access to a file's mount
* @file: the file who's mount on which to take a write
*
- * This is like mnt_want_write, but it takes a file and can
- * do some optimisations if the file is open for write already
+ * This is like mnt_want_write, but it skips getting write access to the mount
+ * if the file is already open for writing. The freeze protection is still
+ * done. This must be paired with mnt_drop_write_file.
*/
int mnt_want_write_file(struct file *file)
{
@@ -449,7 +425,8 @@ EXPORT_SYMBOL_GPL(mnt_drop_write);
void __mnt_drop_write_file(struct file *file)
{
- __mnt_drop_write(file->f_path.mnt);
+ if (!(file->f_mode & FMODE_WRITER))
+ __mnt_drop_write(file->f_path.mnt);
}
void mnt_drop_write_file(struct file *file)
diff --git a/include/linux/mount.h b/include/linux/mount.h
index de657bd211fa64..29d216f927c28c 100644
--- a/include/linux/mount.h
+++ b/include/linux/mount.h
@@ -78,7 +78,6 @@ struct path;
extern int mnt_want_write(struct vfsmount *mnt);
extern int mnt_want_write_file(struct file *file);
-extern int mnt_clone_write(struct vfsmount *mnt);
extern void mnt_drop_write(struct vfsmount *mnt);
extern void mnt_drop_write_file(struct file *file);
extern void mntput(struct vfsmount *mnt);
--
2.26.2
Re: [git pull] uaccess i915
The pull request you sent on Wed, 10 Jun 2020 21:28:37 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git uaccess.i915 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/3a8557e1aed0043d526f304a1f500108c8976b78 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [git pull] vfs misc
The pull request you sent on Wed, 10 Jun 2020 21:30:19 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.misc has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4dbb29fe9dae033a375f231da9cc27aaa09d2580 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
