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
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
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 aborti
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 s
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().
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 mai
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 a
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
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 = ge
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 mea
)
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 in
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 gua
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
> thereof.
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 decla
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 de
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 li
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
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? -
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 name
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 tak
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 devic
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 differen
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 th
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 compat_ptr
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; compat_ptr
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
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 tree
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 ipc_namespa
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
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 maki
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 ca
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 k
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
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 thr
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.
>
>
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;
>
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
http://drive
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 uniform
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 strict
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 pushed...
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;
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 yo
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
> >
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:
> +
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
> > ---
> > drivers/stagi
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 changed, 2 insertions(+), 1
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?
>
> > Signed-off-
On Sun, Dec 25, 2016 at 10:34:54PM +, Jonathan Cameron wrote:
>
>
> On 25 December 2016 20:14:09 GMT+00:00, Al Viro
> wrote:
> >On Sun, Dec 25, 2016 at 01:41:06PM -0600, Scott Matheina wrote:
> >> Across the file, variables were sometimes upper case, some time
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 y
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 o
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
> ta
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 public mailing
> > list availa
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);
Umm...
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 = cp
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 try
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: war
On Tue, Dec 09, 2014 at 10:56:12PM -0800, Shalin Mehta wrote:
> From: Shalin Mehta
>
> 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. Where as here, the __us
rivers/staging/lustre where struct iovec should not be struct kvec. As for
everything else, see below.
commit 82fa028f2b462743aeeb9b973d02733801b2f8e6
Author: Al Viro
Date: Sat Nov 29 12:24:20 2014 -0500
lustre: don't use iovec instead of kvec
Signed-off-by: Al Viro
diff --gi
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 somethin
> 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 deleti
> of not-yet-committed writes to the log buffer.
>
> Signed-off-by: Daniel Thompson
> Cc: Al Viro
Applied
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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 whethe
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 ?
63 matches
Mail list logo
