Re: [driver-core:debugfs_cleanup 4/5] fs/d_path.c:59 prepend() warn: unsigned 'p->len' is never less than zero.

On Sat, Jan 01, 2022 at 02:08:54PM +0100, Greg Kroah-Hartman wrote: > On Fri, Dec 31, 2021 at 07:35:07PM +0000, Al Viro wrote: > > On Sat, Jan 01, 2022 at 01:08:41AM +0800, kernel test robot wrote: > > > tree: > > > https://git.kernel.org/pub/scm/linux/kernel

Re: [driver-core:debugfs_cleanup 4/5] fs/d_path.c:59 prepend() warn: unsigned 'p->len' is never less than zero.

On Sat, Jan 01, 2022 at 01:08:41AM +0800, kernel test robot wrote: > tree: > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git > debugfs_cleanup > head: a04bbe0a2c7e98669e11a47f94e53dd8228bbeba > commit: e95d5bed5d58c2f5352969369827e7135fa2261e [4/5] fs: make d_path-like

Re: [PATCH 2/2] binder: Use receive_fd() to receive file from another process

On Fri, Apr 16, 2021 at 05:30:41PM +, Al Viro wrote: > On Fri, Apr 16, 2021 at 05:58:15PM +0200, Christian Brauner wrote: > > > They could probably refactor this but I'm not sure why they'd bother. If > > they fail processing any of those files they end up aborting the >

Re: [PATCH 2/2] binder: Use receive_fd() to receive file from another process

On Fri, Apr 16, 2021 at 05:58:15PM +0200, Christian Brauner wrote: > They could probably refactor this but I'm not sure why they'd bother. If > they fail processing any of those files they end up aborting the > whole transaction. > (And the original code didn't check the error code btw.) Wait a

Re: [PATCH 2/2] binder: Use receive_fd() to receive file from another process

On Fri, Apr 16, 2021 at 06:00:38PM +0200, Christian Brauner wrote: > (dma_buf_fd() seems like another good candidate. But again, I don't have > any plans to shove this down anyone's throat.) Sure, there are candidates for such a helper. Just as there are legitimate users of anon_inode_getfd().

Re: [PATCH 2/2] binder: Use receive_fd() to receive file from another process

On Fri, Apr 16, 2021 at 05:13:10PM +0200, Christian Brauner wrote: > My point here was more that the _file_ has already been opened _before_ > that call to io_uring_add_task_file(). But any potential non-trivial > side-effects of opening that file that you correctly pointed out in an > earlier

Re: [PATCH 2/2] binder: Use receive_fd() to receive file from another process

On Fri, Apr 16, 2021 at 03:42:52PM +0200, Christian Brauner wrote: > > > are drivers/dma-buf/sw_sync.c and drivers/dma-buf/sync_file.c, etc. > > > > FWIW, pretty much all ioctls that return descriptor as part of a structure > > stored to user-supplied address tend to be that way; some don't have

Re: [PATCH 2/2] binder: Use receive_fd() to receive file from another process

On Fri, Apr 16, 2021 at 05:19:50AM +, Al Viro wrote: > On Thu, Apr 01, 2021 at 12:40:34PM +0200, Christian Brauner wrote: > > and see whether all of them can be switched to simply using > > receive_fd(). I did a completely untested rough sketch to illustrate > > what I

Re: [PATCH 2/2] binder: Use receive_fd() to receive file from another process

On Thu, Apr 01, 2021 at 12:40:34PM +0200, Christian Brauner wrote: > My suggestion was to look at all the places were we currently open-code > this in drivers/: > > drivers/android/binder.c: int fd = > get_unused_fd_flags(O_CLOEXEC); > drivers/char/tpm/tpm_vtpm_proxy.c: fd =

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

[git pull] uaccess comedi compat

) Al Viro (10): comedi: move compat ioctl handling to native fops comedi: get rid of indirection via translated_ioctl() comedi: get rid of compat_alloc_user_space() mess in COMEDI_CHANINFO compat comedi: get rid of compat_alloc_user_space() mess

Re: [PATCH v2 2/3] binder: do not initialize locals passed to copy_from_user()

On Thu, Mar 05, 2020 at 10:03:25AM +0100, Rasmus Villemoes wrote: > Does copy_from_user guarantee to zero-initialize the remaining buffer if > copying fails partway through? That's guaranteed, short of raw_copy_from_user() being completely broken. What raw_copy_from_user() implementation must

Re: [PATCH] staging: wfx: add gcc extension __force cast

On Mon, Nov 11, 2019 at 08:28:52PM +, Al Viro wrote: > So it smells like a remote buffer overrun, little-endian or not. > And at that point I would start looking for driver original authors with > some rather pointed questions about the validation of data and lack > there

Re: [PATCH] staging: wfx: add gcc extension __force cast

On Mon, Nov 11, 2019 at 01:51:33PM +, Jules Irenge wrote: > > > NAK. force-cast (and it's not a gcc extension, BTW - it's sparse) is > > basically > > "I know better; the code is right, so STFU already". *IF* > > counters.count_... > > is really little-endian 32bit, then why isn't it

Re: [PATCH] staging: wfx: add gcc extension __force cast

On Fri, Nov 08, 2019 at 11:38:37PM +, Jules Irenge wrote: > Add gcc extension __force and __le32 cast to fix warning issued by Sparse > tool."warning: cast to restricted __le32" > > Signed-off-by: Jules Irenge > --- > drivers/staging/wfx/debug.c | 2 +- > 1 file changed, 1 insertion(+), 1

Re: [PATCH] staging: comedi: Capitalize macro name to fix camelcase checkpatch warning

On Sun, Oct 06, 2019 at 07:49:03PM +0100, Jules Irenge wrote: [mA vs. MA] Table 5. SI prefixes Factor NameSymbol 10^6megaM 10^-3 milli m Confusing one for another (especially for electrical units) can be... spectacular. FYI, 1mA is more or less what you get if you

Re: [PATCH] staging: exfat: cleanup braces for if/else statements

On Tue, Sep 03, 2019 at 06:47:32PM +0200, Valentin Vidic wrote: > + } else if (uni == 0x) { > skip = TRUE; While we are at it, could you get rid of that 'TRUE' macro? Or added #define THE_TRUTH_AND_THATS_CUTTIN_ME_OWN_THROAT true if you want

Re: [PATCH v2 03/24] erofs: add super block operations

On Sun, Jul 21, 2019 at 11:08:42AM +0800, Gao Xiang wrote: > It is for debugging use as you said below, mainly for our internal > testers whose jobs are > to read kmsg logs and catch kernel problems. sb->s_id (device number) > maybe not > straight-forward for them compared with dev_name... Huh?

Re: [PATCH v2 03/24] erofs: add super block operations

On Thu, Jul 11, 2019 at 10:57:34PM +0800, Gao Xiang wrote: > This commit adds erofs super block operations, including (u)mount, > remount_fs, show_options, statfs, in addition to some private > icache management functions. Could you explain what's the point of this > + /* save the device

Re: Procedure questions - new filesystem driver..

On Mon, Jul 08, 2019 at 08:37:42PM -0400, Valdis Klētnieks wrote: > I have an out-of-tree driver for the exfat file system that I beaten into > shape > for upstreaming. The driver works, and passes sparse and checkpatch (except > for a number of line-too-long complaints). > > Do you want this

Re: [PATCH V2] staging: fieldbus: anybus-s: force endiannes annotation

On Tue, Apr 30, 2019 at 09:32:20AM -0400, Sven Van Asbroeck wrote: > On Tue, Apr 30, 2019 at 12:19 AM Al Viro wrote: > > > > ... not that there's much sense keeping ->fieldbus_type in host-endian, > > while we are at it. > > Interesting! Suppose we make de

Re: [PATCH V2] staging: fieldbus: anybus-s: force endiannes annotation

On Tue, Apr 30, 2019 at 05:33:10AM +0200, Nicholas Mc Guire wrote: > ok - my bad thn - I had assumed that using __force is reasonable > if the handling is correct and its a localized conversoin only > like var = be16_to_cpu(var) which evaded introducing additinal > variables just to have

Re: [PATCH V2] staging: fieldbus: anybus-s: force endiannes annotation

On Tue, Apr 30, 2019 at 04:22:38AM +0200, Nicholas Mc Guire wrote: > On Mon, Apr 29, 2019 at 10:03:36AM -0400, Sven Van Asbroeck wrote: > > On Mon, Apr 29, 2019 at 2:11 AM Nicholas Mc Guire wrote: > > > > > > V2: As requested by Sven Van Asbroeck make the > > > impact of the patch clear in

Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl

On Thu, Apr 25, 2019 at 05:55:23PM +0200, Arnd Bergmann wrote: > On Thu, Apr 25, 2019 at 5:35 PM Al Viro wrote: > > > > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote: > > > > > If I understand your patch description well, using com

Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl

On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote: > If I understand your patch description well, using compat_ptr_ioctl > only works if the driver is not for s390, right? No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl and be done with that;

Re: [PATCH] tty: Fix WARNING in tty_set_termios

On Fri, Jan 25, 2019 at 04:29:05PM -0700, Shuah Khan wrote: > tty_set_termios() has the following WARMN_ON which can be triggered with a > syscall to invoke TIOCGETD __NR_ioctl. > > WARN_ON(tty->driver->type == TTY_DRIVER_TYPE_PTY && > tty->driver->subtype == PTY_TYPE_MASTER); >

Re: [PATCH 0/5] binderfs: debug galore

On Fri, Jan 18, 2019 at 03:53:39PM +0100, Christian Brauner wrote: > Hey everyone, > > Al gave me a really helpful review of binderfs and pointed out a range > of bugs. The most obvious and serious ones have fortunately already been > taken care of by patches sitting in Greg's char-misc-linus

Re: [PATCH 3/5] binderfs: rework binderfs_fill_super()

On Fri, Jan 18, 2019 at 03:53:42PM +0100, Christian Brauner wrote: > static int binderfs_fill_super(struct super_block *sb, void *data, int > silent) > { > + int ret; > struct binderfs_info *info; > - int ret = -ENOMEM; > struct inode *inode = NULL; > struct

Re: [PATCH 2/5] binderfs: prevent renaming the control dentry

On Fri, Jan 18, 2019 at 03:53:41PM +0100, Christian Brauner wrote: > We don't allow to unlink it since it is crucial for binderfs to be useable > but if we allow to rename it we make the unlink trivial to bypass. So > prevent renaming too and simply treat the control dentry as immutable. > > Take

Re: [PATCH v2] binder: fix use-after-free due to ksys_close() during fdget()

lem is fixed by deferring the fd close using task_work_add() > so ksys_close() is called after returning from binder_ioctl(). > > Fixes: 44d8047f1d87a ("binder: use standard functions to allocate fds") > Suggested-by: Al Viro > Signed-off-by: Todd Kjos Umm... IMO you are m

Re: [PATCH v2] binder: fix use-after-free due to fdget() optimization

On Wed, Dec 05, 2018 at 04:21:55PM -0800, Todd Kjos wrote: > > How about grabbing the references to all victims (*before* screwing with > > ksys_close()), sticking them into a structure with embedded callback_head > > and using task_work_add() on it, the callback doing those fput()? > > > > The

Re: [PATCH v2] binder: fix use-after-free due to fdget() optimization

On Wed, Dec 05, 2018 at 01:16:01PM -0800, Todd Kjos wrote: > 44d8047f1d87a ("binder: use standard functions to allocate fds") > exposed a pre-existing issue in the binder driver. > > fdget() is used in ksys_ioctl() as a performance optimization. > One of the rules associated with fdget() is that

Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg

On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote: > Acked-by: Darren Hart (VMware) > > As for a longer term solution, would it be possible to init fops in such > a way that the compat_ioctl call defaults to generic_compat_ioctl_ptrarg > so we don't have to duplicate this boilerplate

Re: [PATCH] staging: speakup: fix wraparound in uaccess length check

On Fri, Jul 13, 2018 at 12:29:36AM +0200, Jann Horn wrote: > From: Samuel Thibault > > From: Samuel Thibault > > If softsynthx_read() is called with `count < 3`, `count - 3` wraps, causing > the loop to copy as much data as available to the provided buffer. If > softsynthx_read() is invoked

Re: simplify procfs code for seq_file instances V3

On Wed, May 16, 2018 at 11:43:04AM +0200, Christoph Hellwig wrote: > We currently have hundreds of proc files that implement plain, read-only > seq_file based interfaces. This series consolidates them using new > procfs helpers that take the seq_operations or simple show callback > directly. > >

Re: simplify procfs code for seq_file instances V2

On Sun, May 06, 2018 at 08:19:49PM +0300, Alexey Dobriyan wrote: > +++ b/fs/proc/internal.h > @@ -48,8 +48,8 @@ struct proc_dir_entry { > const struct seq_operations *seq_ops; > int (*single_show)(struct seq_file *, void *); > }; > - unsigned int state_size; >

Re: KASAN: use-after-free Read in remove_wait_queue

On Mon, Feb 12, 2018 at 06:11:02PM +0100, Dmitry Vyukov wrote: > The commit on which it was triggered already includes this fix. So > there must be another bug. Any chance of bisecting it? ___ devel mailing list de...@linuxdriverproject.org

Re: [PATCH] Staging: netlogic: platform_net: Fixed '(' at the EOL

On Sun, Jan 14, 2018 at 11:47:11PM +0530, Naveen Panwar wrote: > Removed '(' from the end of line, coding style issue. The one and only reason for warnings is that they point to places more likely to be dodgy. There is no inherent value in having e.g. checkpatch.pl STFU, all wanking about

Re: [PATCH v2] binder: fix proc->files use-after-free

On Thu, Nov 16, 2017 at 09:56:50AM -0800, Todd Kjos wrote: > +static struct files_struct *binder_get_files_struct(struct binder_proc *proc) > +{ > + return get_files_struct(proc->tsk); > +} Hell, _no_. You should never, ever use the result of get_files_struct() for write access. It's

Re: [PATCH] staging: pi433: fix missing break in switch statement.

On Thu, Nov 09, 2017 at 05:19:55PM +, Colin King wrote: > From: Colin Ian King > > The PI433_IOC_WR_RX_CFG case is missing a break and will fall through > to the default case and errorenously return -EINVAL. Fix this by > adding in missing break. Folded and

Re: [PATCH] lustre: check copy_from_iter/copy_to_iter return code

On Thu, Jul 13, 2017 at 10:57:59PM +0200, Arnd Bergmann wrote: > Thanks for testing it! > > That means we did not copy any data and the kernel continues with > an uninitialized buffer, right? The problem may be the definition of > > struct kib_immediate_msg { > struct lnet_hdr ibim_hdr;

Re: [PATCH 001/001] drivers/staging/vt6656/main_usb.c: checkpatch warning

On Fri, Mar 31, 2017 at 08:52:50PM -0700, Joe Perches wrote: > > MILD SUGGESTION: don't spell the function name out in format strings; > > "this_function: foo is %d", n > > might be better off as > > "%s: foo is %d", __func__, n > > in case you ever move it to another function or rename

Re: [PATCH 001/001] drivers/staging/vt6656/main_usb.c: checkpatch warning

On Fri, Mar 31, 2017 at 08:36:22PM -0700, Joe Perches wrote: > On Sat, 2017-04-01 at 04:32 +0100, Al Viro wrote: > > On Fri, Mar 31, 2017 at 06:59:19PM -0700, Chewie Lin wrote: > > > Replace string with formatted arguments in the dev_warn() call. It removes > >

Re: [PATCH 001/001] drivers/staging/vt6656/main_usb.c: checkpatch warning

On Fri, Mar 31, 2017 at 06:59:19PM -0700, Chewie Lin wrote: > Replace string with formatted arguments in the dev_warn() call. It removes > the checkpatch warning: > > WARNING: Prefer using "%s", __func__ to embedded function names > #417: FILE: main_usb.c:417: > +

Re: [Outreachy kernel] [PATCH] staging: android: Replace strcpy with strlcpy

On Sat, Mar 11, 2017 at 09:47:30PM +0100, Julia Lawall wrote: > > > On Sun, 12 Mar 2017, simran singhal wrote: > > > Replace strcpy with strlcpy as strcpy does not check for buffer > > overflow. > > This is found using Flawfinder. > > > > Signed-off-by: simran singhal

Re: [PATCH] staging: android: Replace strcpy with strlcpy

On Sun, Mar 12, 2017 at 02:10:01AM +0530, simran singhal wrote: > Replace strcpy with strlcpy as strcpy does not check for buffer > overflow. > This is found using Flawfinder. > > Signed-off-by: simran singhal > --- > drivers/staging/android/ashmem.c | 3 ++- > 1 file

Re: [PATCH]staging: fbtft: Fix sparse warnings about endianness

On Tue, Feb 14, 2017 at 09:18:25AM -0800, Greg KH wrote: > On Tue, Feb 14, 2017 at 04:53:10PM +0800, maomao xu wrote: > > Fixed sparse warnings about endianness. E.g.: > > > > warning: incorrect type in assignment (different base types) > > Why are these lines indented? > > >

Re: [PATCHv4 2/8] Fixed variables not being consistently lower case

On Sun, Dec 25, 2016 at 10:34:54PM +, Jonathan Cameron wrote: > > > On 25 December 2016 20:14:09 GMT+00:00, Al Viro <v...@zeniv.linux.org.uk> > wrote: > >On Sun, Dec 25, 2016 at 01:41:06PM -0600, Scott Matheina wrote: > >> Across the file, variables were

Re: [PATCHv4 2/8] Fixed variables not being consistently lower case

On Sun, Dec 25, 2016 at 01:41:06PM -0600, Scott Matheina wrote: > Across the file, variables were sometimes upper case, some times > lower case, this fix addresses a few of the instances with this > inconsistency. NAK. Go learn C and don't come back until you've done that. If somebody has told

Re: [PATCH 0/8] Sparse warning fixes in Lustre.

On Wed, Dec 07, 2016 at 05:41:26PM -0500, Oleg Drokin wrote: > This set of fixes aims at sparse warnings. Speaking of the stuff sparse catches there: class_process_proc_param(). I've tried to describe what I think of that Fine Piece Of Software several times, but I had to give up - my command of

Re: [RFC 0/6] Module for tracking/accounting shared memory buffers

On Tue, Oct 11, 2016 at 04:50:04PM -0700, Ruchi Kandoi wrote: > memtrack maintains a per-process list of shared buffer references, which is > exported to userspace as /proc/[pid]/memtrack. Buffers can be optionally > "tagged" with a short string: for example, Android userspace would use this >

Re: [PATCH] staging/ion: Add support to get ion handle from dma buf

On Wed, Jan 06, 2016 at 10:21:33AM -0800, Linus Torvalds wrote: > On Wed, Jan 6, 2016 at 1:06 AM, Dan Carpenter > wrote: > > It's not really necessary to CC linux-kernel. No one reads it. Some of us still do. > > I only send patches there when there isn't another

Re: [PATCH] staging: most: add __iomem for io_base and registers

On Sat, Jan 02, 2016 at 08:30:21PM +, Hugo Camboulive wrote: > This removes a few Sparse warnings. > + g.dim2 = (struct dim2_regs __iomem *)dim_base_address; > -u8 dim_startup(void *dim_base_address, u32 mlb_clock); > +u8 dim_startup(void __iomem *dim_base_address, u32 mlb_clock);

Re: [PATCH v2] staging: rtl8723au: Fix sparse errors in rtl8723a_cmd.c

On Tue, Oct 06, 2015 at 12:32:28AM -0400, Jacob Kiefer wrote: > int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, u8 *param) > { > - *((u32 *)param) = cpu_to_le32(*((u32 *)param)); > + __le32 leparam; > > - FillH2CCmd(padapter, RSSI_SETTING_EID, 3, param); > + leparam =

use of opaque subject lines

On Mon, Feb 02, 2015 at 08:13:10PM +0100, Andreas Ruprecht wrote: On a serious note: I do understand what you're getting at, I don't take that personally (and I will send a v2 addressing the things above), but honestly, this kind of answer might just be a real turn-off for other people trying

Re: [PATCH] staging: lustre: osc: Fix sparse warning about osc_init

On Mon, Feb 02, 2015 at 02:36:43PM +0100, Andreas Ruprecht wrote: When running sparse on the osc/ subdirectory, it shows the following warning: andreas@workbox:~/linux-next$ make C=1 M=drivers/staging/lustre/lustre/osc/ [...] drivers/staging/lustre/lustre/osc/osc_request.c:3335:12: warning:

Re: [PATCH] staging: lustre: Fix the warning messages about casting without __user macro

On Tue, Dec 09, 2014 at 10:56:12PM -0800, Shalin Mehta wrote: From: Shalin Mehta shalinmeht...@gmail.com This issue is showed up while compiling with sparse. The iov_base in struct iovec struct explicitly declares that the assigned value should be user space pointer with __user macro.

Re: [PATCH] staging:lustre:lnet: Incorrect type in assignment

drivers/staging/lustre where struct iovec should not be struct kvec. As for everything else, see below. commit 82fa028f2b462743aeeb9b973d02733801b2f8e6 Author: Al Viro v...@zeniv.linux.org.uk Date: Sat Nov 29 12:24:20 2014 -0500 lustre: don't use iovec instead of kvec Signed-off

Re: [PATCH] staging: lustre: fix pointer declarations

On Tue, Nov 25, 2014 at 09:44:21PM +0100, Zahari Doychev wrote: This patch fixes pointer declarations from void * to void __user * in order to remove some sparse warnings. _Are_ those userland addresses, though? Quick grep shows that in the only caller of lnet_copy_iov2flat() we have something

Re: [PATCH] staging: lustre: socklnd: sparse warning fix

the same value casted the same way few lines below: csum = ksocknal_csum(~0, (void *)tx-tx_iov[0].iov_base, then it seems like a typo in LASSERT() that is got fixed drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib-linux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH v3.18-rc2] staging: android: logger: Fix log corruption regression

. Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org Cc: Al Viro v...@zeniv.linux.org.uk Applied ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH resend] staging, lustre: fix a sparse error

On Fri, Oct 10, 2014 at 11:21:16AM +0800, WANG Chao wrote: I think __user annotation is for no dereferencing in kernel space. In this case, I think it's fine to override this error by __force. Because they're pointers with identical target types. Umm... The real question seems to be whether

Re: [RFC PATCH] vsnprintf: Remove use of %n and convert existing uses

On Wed, Sep 11, 2013 at 05:04:17PM -0700, Joe Perches wrote: On Thu, 2013-09-12 at 08:40 +0900, Tetsuo Handa wrote: Joe Perches wrote: - seq_printf(m, %s%d%n, con-name, con-index, len); + len = seq_printf(m, %s%d, con-name, con-index); Isn't len always 0 or -1 ? Right. Well