Re: [PATCH 1/2] MAINTAINERS: fix broken doc refs due to yaml conversion
Em Mon, 12 Oct 2020 14:21:14 -0500 Rob Herring escreveu: > On Fri, Oct 09, 2020 at 02:15:30PM +0200, Mauro Carvalho Chehab wrote: > > Several *.txt files got converted to yaml. Update their > > references at MAINTAINERS file accordingly. > > > > Signed-off-by: Mauro Carvalho Chehab > > --- > > Documentation/devicetree/bindings/clock/hi6220-clock.txt | 2 +- > > MAINTAINERS | 9 - > > .../devicetree/bindings/net/wireless/silabs,wfx.yaml | 2 +- > > 3 files changed, 6 insertions(+), 7 deletions(-) > > Doesn't apply for me. It is based on the top of -next, so perhaps it depends on some other changes that aren't upstream yet and comes from other trees. I could try to split it, but I guess the easiest way is to just push this one by the end of the merge window, together with the remaining patches I have left, fixing the other doc build issues. Would that work for you? Thanks, Mauro ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC PKS/PMEM 24/58] fs/freevxfs: Utilize new kmap_thread()
> - kaddr = kmap(pp); > + kaddr = kmap_thread(pp); > memcpy(kaddr, vip->vii_immed.vi_immed + offset, PAGE_SIZE); > - kunmap(pp); > + kunmap_thread(pp); You only Cced me on this particular patch, which means I have absolutely no idea what kmap_thread and kunmap_thread actually do, and thus can't provide an informed review. That being said I think your life would be a lot easier if you add helpers for the above code sequence and its counterpart that copies to a potential hughmem page first, as that hides the implementation details from most users. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 20/24] MAINTAINERS: fix broken doc refs due to yaml conversion
Several *.txt files got converted to yaml. Update their references at MAINTAINERS file accordingly. Acked-by: Stephen Boyd Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/clock/hi6220-clock.txt | 2 +- MAINTAINERS | 9 - .../devicetree/bindings/net/wireless/silabs,wfx.yaml | 2 +- 3 files changed, 6 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/clock/hi6220-clock.txt b/Documentation/devicetree/bindings/clock/hi6220-clock.txt index ef3deb7b86ea..17ac4a3dd26a 100644 --- a/Documentation/devicetree/bindings/clock/hi6220-clock.txt +++ b/Documentation/devicetree/bindings/clock/hi6220-clock.txt @@ -4,7 +4,7 @@ Clock control registers reside in different Hi6220 system controllers, please refer the following document to know more about the binding rules for these system controllers: -Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt +Documentation/devicetree/bindings/arm/hisilicon/hisilicon.yaml Required Properties: diff --git a/MAINTAINERS b/MAINTAINERS index f1eeef654caa..891b735233d3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -978,7 +978,7 @@ M: Michael Hennerich L: linux-...@vger.kernel.org S: Supported W: http://ez.analog.com/community/linux-device-drivers -F: Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.txt +F: Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml F: drivers/iio/adc/ad7768-1.c ANALOG DEVICES INC AD7780 DRIVER @@ -3867,7 +3867,7 @@ M:Roger Quadros L: linux-...@vger.kernel.org S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git -F: Documentation/devicetree/bindings/usb/cdns-usb3.txt +F: Documentation/devicetree/bindings/usb/cdns,usb3.yaml F: drivers/usb/cdns3/ CADET FM/AM RADIO RECEIVER DRIVER @@ -7919,7 +7919,7 @@ HISILICON LPC BUS DRIVER M: john.ga...@huawei.com S: Maintained W: http://www.hisilicon.com -F: Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt +F: Documentation/devicetree/bindings/arm/hisilicon/low-pin-count.yaml F: drivers/bus/hisi_lpc.c HISILICON NETWORK SUBSYSTEM 3 DRIVER (HNS3) @@ -14910,7 +14910,6 @@ RENESAS ETHERNET DRIVERS R: Sergei Shtylyov L: net...@vger.kernel.org L: linux-renesas-...@vger.kernel.org -F: Documentation/devicetree/bindings/net/renesas,*.txt F: Documentation/devicetree/bindings/net/renesas,*.yaml F: drivers/net/ethernet/renesas/ F: include/linux/sh_eth.h @@ -18114,7 +18113,7 @@ M: Yu Chen M: Binghui Wang L: linux-...@vger.kernel.org S: Maintained -F: Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt +F: Documentation/devicetree/bindings/phy/hisilicon,hi3660-usb3.yaml F: drivers/phy/hisilicon/phy-hi3660-usb3.c USB ISP116X DRIVER diff --git a/drivers/staging/wfx/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml b/drivers/staging/wfx/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml index 43b5630c0407..510edd12ed19 100644 --- a/drivers/staging/wfx/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml +++ b/drivers/staging/wfx/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml @@ -24,7 +24,7 @@ description: In addition, it is recommended to declare a mmc-pwrseq on SDIO host above WFx. Without it, you may encounter issues with warm boot. The mmc-pwrseq should be compatible with mmc-pwrseq-simple. Please consult -Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt for more +Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml for more information. For SPI':' -- 2.26.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 01/23] dt-bindings: introduce silabs,wfx.yaml
On Mon, Oct 12, 2020 at 12:46:26PM +0200, Jerome Pouiller wrote: > From: Jérôme Pouiller > > Signed-off-by: Jérôme Pouiller > --- > .../bindings/net/wireless/silabs,wfx.yaml | 125 ++ > 1 file changed, 125 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml > > diff --git a/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml > b/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml > new file mode 100644 > index ..43b5630c0407 > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml > @@ -0,0 +1,125 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +# Copyright (c) 2020, Silicon Laboratories, Inc. > +%YAML 1.2 > +--- > + > +$id: http://devicetree.org/schemas/net/wireless/silabs,wfx.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Silicon Labs WFxxx devicetree bindings > + > +maintainers: > + - Jérôme Pouiller > + > +description: > + The WFxxx chip series can be connected via SPI or via SDIO. What does this chip do? WiFi or some other wireless? > + > + For SDIO':' > + > +The driver is able to detect a WFxxx chip on SDIO bus by matching its > Vendor > +ID and Product ID. However, driver will only provide limited features in > +this case. Thus declaring WFxxx chip in device tree is recommended (and > may > +become mandatory in the future). > + > +In addition, it is recommended to declare a mmc-pwrseq on SDIO host above > +WFx. Without it, you may encounter issues with warm boot. The mmc-pwrseq > +should be compatible with mmc-pwrseq-simple. Please consult > +Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt for more > +information. > + > + For SPI':' > + > +In add of the properties below, please consult > +Documentation/devicetree/bindings/spi/spi-controller.yaml for optional > SPI > +related properties. > + > + Note that in add of the properties below, the WFx driver also supports > + `mac-address` and `local-mac-address` as described in > + Documentation/devicetree/bindings/net/ethernet.txt Note what ethernet.txt contains... This should have a $ref to ethernet-controller.yaml to express the above. You can add 'mac-address: true' if you want to be explicit about what properties are used. > + > +properties: > + compatible: > +const: silabs,wf200 blank line between each DT property. > + reg: > +description: > + When used on SDIO bus, must be set to 1. When used on SPI bus, > it is > + the chip select address of the device as defined in the SPI devices > + bindings. > +maxItems: 1 > + spi-max-frequency: > +description: (SPI only) Maximum SPI clocking speed of device in Hz. No need to redefine a common property. > +maxItems: 1 Not an array. Just need: spi-max-frequency: true > + interrupts: > +description: The interrupt line. Triggers IRQ_TYPE_LEVEL_HIGH and > + IRQ_TYPE_EDGE_RISING are both supported by the chip and the driver. > When > + SPI is used, this property is required. When SDIO is used, the > "in-band" > + interrupt provided by the SDIO bus is used unless an interrupt is > defined > + in the Device Tree. > +maxItems: 1 > + reset-gpios: > +description: (SPI only) Phandle of gpio that will be used to reset chip > + during probe. Without this property, you may encounter issues with warm > + boot. (For legacy purpose, the gpio in inverted when compatible == > + "silabs,wfx-spi") > + > + For SDIO, the reset gpio should declared using a mmc-pwrseq. > +maxItems: 1 > + wakeup-gpios: > +description: Phandle of gpio that will be used to wake-up chip. Without > this > + property, driver will disable most of power saving features. > +maxItems: 1 > + config-file: > +description: Use an alternative file as PDS. Default is `wf200.pds`. Only > + necessary for development/debug purpose. 'firmware-name' is typically what we'd use here. Though if just for debug/dev, perhaps do a debugfs interface for this instead. As DT should come from the firmware/bootloader, requiring changing the DT for dev/debug is not the easiest workflow compared to doing something from userspace. > +maxItems: 1 Looks like a string, not an array. > + > +required: > + - compatible > + - reg Will need additionalProperties or unevaluatedProperties depending on whether you list out properties from ethernet-controller.yaml or not. Rob ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Fri, 9 Oct 2020, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> The kmap() calls in this FS are localized to a single thread. To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
>
> Cc: Nicolas Pitre
> Signed-off-by: Ira Weiny
Acked-by: Nicolas Pitre
> fs/cramfs/inode.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> index 912308600d39..003c014a42ed 100644
> --- a/fs/cramfs/inode.c
> +++ b/fs/cramfs/inode.c
> @@ -247,8 +247,8 @@ static void *cramfs_blkdev_read(struct super_block *sb,
> unsigned int offset,
> struct page *page = pages[i];
>
> if (page) {
> - memcpy(data, kmap(page), PAGE_SIZE);
> - kunmap(page);
> + memcpy(data, kmap_thread(page), PAGE_SIZE);
> + kunmap_thread(page);
> put_page(page);
> } else
> memset(data, 0, PAGE_SIZE);
> @@ -826,7 +826,7 @@ static int cramfs_readpage(struct file *file, struct page
> *page)
>
> maxblock = (inode->i_size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> bytes_filled = 0;
> - pgdata = kmap(page);
> + pgdata = kmap_thread(page);
>
> if (page->index < maxblock) {
> struct super_block *sb = inode->i_sb;
> @@ -914,13 +914,13 @@ static int cramfs_readpage(struct file *file, struct
> page *page)
>
> memset(pgdata + bytes_filled, 0, PAGE_SIZE - bytes_filled);
> flush_dcache_page(page);
> - kunmap(page);
> + kunmap_thread(page);
> SetPageUptodate(page);
> unlock_page(page);
> return 0;
>
> err:
> - kunmap(page);
> + kunmap_thread(page);
> ClearPageUptodate(page);
> SetPageError(page);
> unlock_page(page);
> --
> 2.28.0.rc0.12.gb6a658bd00c9
>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Fri, Oct 9, 2020 at 12:52 PM wrote:
>
> From: Ira Weiny
>
> The kmap() calls in this FS are localized to a single thread. To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
>
> Cc: Nicolas Pitre
> Signed-off-by: Ira Weiny
> ---
> fs/cramfs/inode.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> index 912308600d39..003c014a42ed 100644
> --- a/fs/cramfs/inode.c
> +++ b/fs/cramfs/inode.c
> @@ -247,8 +247,8 @@ static void *cramfs_blkdev_read(struct super_block *sb,
> unsigned int offset,
> struct page *page = pages[i];
>
> if (page) {
> - memcpy(data, kmap(page), PAGE_SIZE);
> - kunmap(page);
> + memcpy(data, kmap_thread(page), PAGE_SIZE);
> + kunmap_thread(page);
Why does this need a sleepable kmap? This looks like a textbook
kmap_atomic() use case.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> On Fri, Oct 9, 2020 at 12:52 PM wrote:
> >
> > From: Ira Weiny
> >
> > The kmap() calls in this FS are localized to a single thread. To avoid
> > the over head of global PKRS updates use the new kmap_thread() call.
> >
> > Cc: Nicolas Pitre
> > Signed-off-by: Ira Weiny
> > ---
> > fs/cramfs/inode.c | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> > index 912308600d39..003c014a42ed 100644
> > --- a/fs/cramfs/inode.c
> > +++ b/fs/cramfs/inode.c
> > @@ -247,8 +247,8 @@ static void *cramfs_blkdev_read(struct super_block *sb,
> > unsigned int offset,
> > struct page *page = pages[i];
> >
> > if (page) {
> > - memcpy(data, kmap(page), PAGE_SIZE);
> > - kunmap(page);
> > + memcpy(data, kmap_thread(page), PAGE_SIZE);
> > + kunmap_thread(page);
>
> Why does this need a sleepable kmap? This looks like a textbook
> kmap_atomic() use case.
There's a lot of code of this form. Could we perhaps have:
static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned int
size)
{
char *vto = kmap_atomic(to);
memcpy(vto, vfrom, size);
kunmap_atomic(vto);
}
in linux/highmem.h ?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Tue, Oct 13, 2020 at 12:37 PM Matthew Wilcox wrote:
>
> On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> > On Fri, Oct 9, 2020 at 12:52 PM wrote:
> > >
> > > From: Ira Weiny
> > >
> > > The kmap() calls in this FS are localized to a single thread. To avoid
> > > the over head of global PKRS updates use the new kmap_thread() call.
> > >
> > > Cc: Nicolas Pitre
> > > Signed-off-by: Ira Weiny
> > > ---
> > > fs/cramfs/inode.c | 10 +-
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> > > index 912308600d39..003c014a42ed 100644
> > > --- a/fs/cramfs/inode.c
> > > +++ b/fs/cramfs/inode.c
> > > @@ -247,8 +247,8 @@ static void *cramfs_blkdev_read(struct super_block
> > > *sb, unsigned int offset,
> > > struct page *page = pages[i];
> > >
> > > if (page) {
> > > - memcpy(data, kmap(page), PAGE_SIZE);
> > > - kunmap(page);
> > > + memcpy(data, kmap_thread(page), PAGE_SIZE);
> > > + kunmap_thread(page);
> >
> > Why does this need a sleepable kmap? This looks like a textbook
> > kmap_atomic() use case.
>
> There's a lot of code of this form. Could we perhaps have:
>
> static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned
> int size)
> {
> char *vto = kmap_atomic(to);
>
> memcpy(vto, vfrom, size);
> kunmap_atomic(vto);
> }
>
> in linux/highmem.h ?
Nice, yes, that could also replace the local ones in lib/iov_iter.c
(memcpy_{to,from}_page())
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote:
> static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned
> int size)
> {
> char *vto = kmap_atomic(to);
>
> memcpy(vto, vfrom, size);
> kunmap_atomic(vto);
> }
>
> in linux/highmem.h ?
You mean, like
static void memcpy_from_page(char *to, struct page *page, size_t offset, size_t
len)
{
char *from = kmap_atomic(page);
memcpy(to, from + offset, len);
kunmap_atomic(from);
}
static void memcpy_to_page(struct page *page, size_t offset, const char *from,
size_t len)
{
char *to = kmap_atomic(page);
memcpy(to + offset, from, len);
kunmap_atomic(to);
}
static void memzero_page(struct page *page, size_t offset, size_t len)
{
char *addr = kmap_atomic(page);
memset(addr + offset, 0, len);
kunmap_atomic(addr);
}
in lib/iov_iter.c? FWIW, I don't like that "highpage" in the name and
highmem.h as location - these make perfect sense regardless of highmem;
they are normal memory operations with page + offset used instead of
a pointer...
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] binder: fix UAF when releasing todo list
On Fri, Oct 09, 2020 at 04:24:55PM -0700, Todd Kjos wrote: > When releasing a thread todo list when tearing down > a binder_proc, the following race was possible which > could result in a use-after-free: > > 1. Thread 1: enter binder_release_work from binder_thread_release > 2. Thread 2: binder_update_ref_for_handle() -> binder_dec_node_ilocked() > 3. Thread 2: dec nodeA --> 0 (will free node) > 4. Thread 1: ACQ inner_proc_lock > 5. Thread 2: block on inner_proc_lock > 6. Thread 1: dequeue work (BINDER_WORK_NODE, part of nodeA) > 7. Thread 1: REL inner_proc_lock > 8. Thread 2: ACQ inner_proc_lock > 9. Thread 2: todo list cleanup, but work was already dequeued > 10. Thread 2: free node > 11. Thread 2: REL inner_proc_lock > 12. Thread 1: deref w->type (UAF) > > The problem was that for a BINDER_WORK_NODE, the binder_work element > must not be accessed after releasing the inner_proc_lock while > processing the todo list elements since another thread might be > handling a deref on the node containing the binder_work element > leading to the node being freed. > > Signed-off-by: Todd Kjos > --- Thanks! Acked-by: Christian Brauner ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 07/23] wfx: add bus_sdio.c
Hello!
On Monday 12 October 2020 12:46:32 Jerome Pouiller wrote:
> +#define SDIO_VENDOR_ID_SILABS0x
> +#define SDIO_DEVICE_ID_SILABS_WF200 0x1000
> +static const struct sdio_device_id wfx_sdio_ids[] = {
> + { SDIO_DEVICE(SDIO_VENDOR_ID_SILABS, SDIO_DEVICE_ID_SILABS_WF200) },
Please move ids into common include file include/linux/mmc/sdio_ids.h
where are all SDIO ids. Now all drivers have ids defined in that file.
> + // FIXME: ignore VID/PID and only rely on device tree
> + // { SDIO_DEVICE(SDIO_ANY_ID, SDIO_ANY_ID) },
What is the reason for ignoring vendor and device ids?
> + { },
> +};
> +MODULE_DEVICE_TABLE(sdio, wfx_sdio_ids);
> +
> +struct sdio_driver wfx_sdio_driver = {
> + .name = "wfx-sdio",
> + .id_table = wfx_sdio_ids,
> + .probe = wfx_sdio_probe,
> + .remove = wfx_sdio_remove,
> + .drv = {
> + .owner = THIS_MODULE,
> + .of_match_table = wfx_sdio_of_match,
> + }
> +};
> --
> 2.28.0
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote:
> On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> > On Fri, Oct 9, 2020 at 12:52 PM wrote:
> > >
> > > From: Ira Weiny
> > >
> > > The kmap() calls in this FS are localized to a single thread. To avoid
> > > the over head of global PKRS updates use the new kmap_thread() call.
> > >
> > > Cc: Nicolas Pitre
> > > Signed-off-by: Ira Weiny
> > > ---
> > > fs/cramfs/inode.c | 10 +-
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> > > index 912308600d39..003c014a42ed 100644
> > > --- a/fs/cramfs/inode.c
> > > +++ b/fs/cramfs/inode.c
> > > @@ -247,8 +247,8 @@ static void *cramfs_blkdev_read(struct super_block
> > > *sb, unsigned int offset,
> > > struct page *page = pages[i];
> > >
> > > if (page) {
> > > - memcpy(data, kmap(page), PAGE_SIZE);
> > > - kunmap(page);
> > > + memcpy(data, kmap_thread(page), PAGE_SIZE);
> > > + kunmap_thread(page);
> >
> > Why does this need a sleepable kmap? This looks like a textbook
> > kmap_atomic() use case.
>
> There's a lot of code of this form. Could we perhaps have:
>
> static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned
> int size)
> {
> char *vto = kmap_atomic(to);
>
> memcpy(vto, vfrom, size);
> kunmap_atomic(vto);
> }
>
> in linux/highmem.h ?
Christoph had the same idea. I'll work on it.
Ira
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Tue, Oct 13, 2020 at 09:01:49PM +0100, Al Viro wrote:
> On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote:
>
> > static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned
> > int size)
> > {
> > char *vto = kmap_atomic(to);
> >
> > memcpy(vto, vfrom, size);
> > kunmap_atomic(vto);
> > }
> >
> > in linux/highmem.h ?
>
> You mean, like
> static void memcpy_from_page(char *to, struct page *page, size_t offset,
> size_t len)
> {
> char *from = kmap_atomic(page);
> memcpy(to, from + offset, len);
> kunmap_atomic(from);
> }
>
> static void memcpy_to_page(struct page *page, size_t offset, const char
> *from, size_t len)
> {
> char *to = kmap_atomic(page);
> memcpy(to + offset, from, len);
> kunmap_atomic(to);
> }
>
> static void memzero_page(struct page *page, size_t offset, size_t len)
> {
> char *addr = kmap_atomic(page);
> memset(addr + offset, 0, len);
> kunmap_atomic(addr);
> }
>
> in lib/iov_iter.c? FWIW, I don't like that "highpage" in the name and
> highmem.h as location - these make perfect sense regardless of highmem;
> they are normal memory operations with page + offset used instead of
> a pointer...
I was thinking along those lines as well especially because of the direction
this patch set takes kmap().
Thanks for pointing these out to me. How about I lift them to a common header?
But if not highmem.h where?
Ira
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC PKS/PMEM 24/58] fs/freevxfs: Utilize new kmap_thread()
On Tue, Oct 13, 2020 at 12:25:44PM +0100, Christoph Hellwig wrote: > > - kaddr = kmap(pp); > > + kaddr = kmap_thread(pp); > > memcpy(kaddr, vip->vii_immed.vi_immed + offset, PAGE_SIZE); > > - kunmap(pp); > > + kunmap_thread(pp); > > You only Cced me on this particular patch, which means I have absolutely > no idea what kmap_thread and kunmap_thread actually do, and thus can't > provide an informed review. Sorry the list was so big I struggled with who to CC and on which patches. > > That being said I think your life would be a lot easier if you add > helpers for the above code sequence and its counterpart that copies > to a potential hughmem page first, as that hides the implementation > details from most users. Matthew Wilcox and Al Viro have suggested similar ideas. https://lore.kernel.org/lkml/20201013205012.gi2046...@iweiny-desk2.sc.intel.com/ Ira ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: comedi: quatech_daqp_cs: Remove repeated word on comment
Remove repeated word on comment.
Signed-off-by: Giovanni Bertao
---
drivers/staging/comedi/drivers/quatech_daqp_cs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/drivers/quatech_daqp_cs.c
b/drivers/staging/comedi/drivers/quatech_daqp_cs.c
index 1b1efa4d31f6..fe4408ebf6b3 100644
--- a/drivers/staging/comedi/drivers/quatech_daqp_cs.c
+++ b/drivers/staging/comedi/drivers/quatech_daqp_cs.c
@@ -164,7 +164,7 @@ static int daqp_clear_events(struct comedi_device *dev, int
loops)
/*
* Reset any pending interrupts (my card has a tendency to require
-* require multiple reads on the status register to achieve this).
+* multiple reads on the status register to achieve this).
*/
while (--loops) {
status = inb(dev->iobase + DAQP_STATUS_REG);
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 00/11] Introduce Simple atomic counters
On 10/10/20 5:09 AM, Peter Zijlstra wrote: On Fri, Oct 09, 2020 at 01:45:43PM -0700, Kees Cook wrote: On Fri, Oct 09, 2020 at 09:37:46PM +0200, Peter Zijlstra wrote: On Fri, Oct 09, 2020 at 09:55:55AM -0600, Shuah Khan wrote: Simple atomic counters api provides interfaces for simple atomic counters that just count, and don't guard resource lifetimes. The interfaces are built on top of atomic_t api, providing a smaller subset of atomic_t interfaces necessary to support simple counters. To what actual purpose?!? AFACIT its pointless wrappery, it gets us nothing. It's not pointless. There is value is separating types for behavioral constraint to avoid flaws. atomic_t provides a native operation. We gained refcount_t for the "must not wrap" type, and this gets us the other side of that behavioral type, which is "wrapping is expected". Separating the atomic_t uses allows for a clearer path to being able to reason about code flow, whether it be a human or a static analyzer. refcount_t got us actual rutime exceptions that atomic_t doesn't. This propsal gets us nothing. atomic_t is very much expected to wrap. The counter wrappers add nothing to the image size, and only serve to confine the API to one that cannot be used for lifetime management. It doesn't add anything period. It doesn't get us new behaviour, it splits a 'can wrap' use-case from a 'can wrap' type. That's sodding pointless. They don't add any new behavior, As Kees mentioned they do give us a way to clearly differentiate atomic usages that can wrap. Let's discuss the problem at hand before dismissing it as pointless. Worse, it mixes 2 unrelated cases into one type, which just makes a mockery of things (all the inc_return users are not statistics, some might even mis-behave if they wrap). You are right that all inc_return usages aren't statistics. There are 3 distinct usages: 1. Stats 2. Cases where wrapping is fine 3. Cases where wrapping could be a problem. In which case, this API shouldn't be used. There is no need to keep inc_return in this API as such. I included it so it can be used for above cases 1 and 2, so the users don't have to call inc() followed by read(). It can be left out of the API. The atomic_t usages in the kernel fall into the following categories: 1. Stats (tolerance for accuracy determines whether they need to be atomic or not). RFC version included non-atomic API for cases when lossiness is acceptable. All these cases use/need just init and inc. There are two variations in this case: a. No checks for wrapping. Use signed value. b. No checks for wrapping, but return unsigned. 2. Reference counters that release resource and rapping could result in use-after-free type problems. There are two variations in this case: a. Increments and decrements aren't bounded. b. Increments and decrements are bounded. Currently tools that flag unsafe atomic_t usages that are candidates for refcount_t conversions don't make a distinction between the two. The second case, since increments and decrements are bounded, it is safe to continue to use it. At the moment there is no good way to tell them apart other than looking at each of these cases. 3. Reference counters that manage/control states. Wrapping is a problem in this case, as it could lead to undefined behavior. These cases don't use test and free, use inc/dec. At the moment there is no good way to tell them apart other than looking at each of these cases. This is addressed by REFCOUNT_SATURATED case. This API addresses 1a. Stats. No checks for wrapping. Use signed value at the moment with plan to add support for unsigned for cases where unsigned is being used. It is possible to cover 2b in this API, so it becomes easier to make a clear distinction the two cases and we can focus on only the atomic_t cases that need to converted to refcount_t. This is easy to do by allowing max. threshold for the variable and checking against that and not letting it go above it. There are several atomic_t usages that use just: -- init or set and inc -- init or set and inc/dec (including the ones that manage state) -- Increments and decrements are bounded Creating a sub-set of atomic_t api would help us with differentiate these cases and make it easy for us identify and fix cases where refcount_t should be used. Would you be open to considering a subset if it addresses 2b and unsigned returns for stats? thanks, -- Shuah ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
