On Fri, Dec 11, 2015 at 08:56:26PM +0100, David Eccher wrote:
> Fix bad unlock balance: ep0_write enter with the locks locked from
> inode.c:1769,
> hence it must exit with spinlock held to avoid double unlock in dev_config.
*Ugh*
Just take that spinlock before the if (retval < 0) and don't drop
On Mon, Mar 28, 2016 at 02:42:43PM +0200, Lars-Peter Clausen wrote:
> In the current implementation functionfs generates a EFAULT for async read
> operations if the read buffer size is larger than the URB data size. Since
> a application does not necessarily know how much data the host side is
> go
d initialize ffs_data *before* calling mount_nodev() and
pass a pointer to it via data.ffs_data. And once it's stored in
sb->s_fs_info, clear data.ffs_data, so that ffs_fs_mount() knows that
it doesn't need to kill the sucker manually - from that point on
we'll have it done by ->kill_sb().
On Sat, Sep 21, 2013 at 01:10:48AM +0200, Michal Nazarewicz wrote:
> On Fri, Sep 20 2013, Al Viro wrote:
> > There's a bunch of failure exits in ffs_fs_mount() with
> > seriously broken recovery logics. Most of that appears to stem
> > from misunderstanding of
On Wed, Oct 08, 2014 at 02:12:18PM -0700, David Cohen wrote:
> use_mm(io_data->mm);
> for (i = 0; i < io_data->nr_segs; i++) {
> + size_t len = min_t(size_t, ret - pos,
> + io_data->iovec[i].iov_len);
> +
On Wed, May 27, 2015 at 11:41:31AM +0100, Rui Miguel Silva wrote:
> do not try to set cancel function in synchronous operations in
> ffs_epfile_{read,write}_iter.
>
> With, 70e60d917 gadget/function/f_fs.c: switch to ->{read,write}_iter()
> if CONFIG_AIO is disable there is no problem as kiocb_set
On Fri, Jun 12, 2015 at 05:51:12PM -0700, John Stultz wrote:
> I'm not super sure what the right fix is, but if do something like the
> following (sorry, whitespace corrupted via copy/paste), I don't seem
> to run into the problem.
Looks sane. Which tree would you prefer it to go through, vfs or
[USB folks Cc'd]
On Mon, Feb 02, 2015 at 03:26:17PM +0100, Christoph Hellwig wrote:
> I would bet the behavior difference is a bug, might be worth to Cc the
> usb folks on this issue. I bet we'd want the more complex behavior
> for both variants.
[Context for USB people: The difference in quest
On Wed, Feb 04, 2015 at 01:17:30PM -0500, Alan Stern wrote:
> On Wed, 4 Feb 2015, Al Viro wrote:
>
> > [USB folks Cc'd]
>
> Incidentally, Al, have you seen this email?
>
> http://marc.info/?l=linux-usb&m=142295011402339&w=2
>
> I encouraged the
On Wed, Feb 04, 2015 at 03:30:32PM -0500, Alan Stern wrote:
> > * this one. Note that you are not guaranteed that ep_config() won't
> > be called more than once - two threads might race in write(2), with the
> > loser
> > getting through mutex_lock_interruptible(&data->lock); in ep_config() o
On Thu, Feb 05, 2015 at 09:24:32AM +0100, Robert Baldyga wrote:
> No, function/f_fs.c and legacy/inode.c are in class (1). They have
> datagram semantics - each vector element is submitted in separate USB
> request. Each single request is sent in separate USB data packet (for
> bulk endpoints it c
On Thu, Feb 05, 2015 at 08:47:29AM +, Al Viro wrote:
> You are confusing datagram-per-syscall (which they are) with
> datagram-per-iovec (which they are definitely not). IOW, they behave
> as UDP sockets - writev() is purely scatter-gather variant of write(),
> with datagram
On Thu, Feb 05, 2015 at 10:29:42AM -0500, Alan Stern wrote:
> On Wed, 4 Feb 2015, Al Viro wrote:
>
> > > > Um... readv() is also going through ->aio_read().
> > >
> > > Why does readv() do this but not read()? Wouldn't it make more sense
> > &
On Thu, Feb 05, 2015 at 10:29:42AM -0500, Alan Stern wrote:
> On Wed, 4 Feb 2015, Al Viro wrote:
>
> > > > Um... readv() is also going through ->aio_read().
> > >
> > > Why does readv() do this but not read()? Wouldn't it make more sense
> > &
From: Al Viro
Signed-off-by: Al Viro
---
drivers/usb/gadget/function/f_fs.c | 136 -
1 file changed, 58 insertions(+), 78 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index 11704e7..04c6542 100644
--- a
From: Al Viro
both on aio and non-aio sides
Signed-off-by: Al Viro
---
drivers/usb/gadget/function/f_fs.c | 86 +++---
1 file changed, 25 insertions(+), 61 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index
From: Al Viro
AIO_PREAD requests call ->aio_read() with iovec on caller's stack, so if
we are going to access it asynchronously, we'd better get ourselves
a copy - the one on kernel stack of aio_run_iocb() won't be there
anymore. function/f_fs.c take care of doing that, lega
From: Al Viro
Signed-off-by: Al Viro
---
drivers/usb/gadget/legacy/inode.c | 355 +++---
1 file changed, 141 insertions(+), 214 deletions(-)
diff --git a/drivers/usb/gadget/legacy/inode.c
b/drivers/usb/gadget/legacy/inode.c
index 9fbbaa0..b825edc 100644
--- a
From: Al Viro
If ffs_epfile_io() fails in AIO case, we end up leaking io_data
(and iovec_copy in case of AIO read).
Signed-off-by: Al Viro
---
drivers/usb/gadget/function/f_fs.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/function
From: Al Viro
Copy iter and kmemdup the underlying array for the copy. Returns
a pointer to result of kmemdup() to be kfree()'d later.
Signed-off-by: Al Viro
---
include/linux/uio.h | 2 ++
mm/iov_iter.c | 15 +++
2 files changed, 17 insertions(+)
diff --git a/in
On Mon, Mar 02, 2015 at 10:13:27AM +0100, Richard Weinberger wrote:
> On Mon, Mar 2, 2015 at 9:28 AM, Alexander Holler wrote:
> > Hello.
> >
> > Commit 7f7f25e82d54870df24d415a7007fbd327da027b (introduced with 3.16) broke
> > dynamic changing of file_operations->[read|write].
> >
> > At least gadg
On Mon, Mar 02, 2015 at 02:02:56PM +0100, Alexander Holler wrote:
> >I exactly did what you've assumed, I've just fixed f_mode but not the
> >already existing races which I haven't introduced. So I was right in not
> >sending a patch as would have been blamed for not rewriting everything
> >as so
On Tue, Mar 03, 2015 at 10:47:14AM -0500, Alan Stern wrote:
> On Tue, 3 Mar 2015, Al Viro wrote:
>
> > Looking at that thing again... why do they need to be dummy? After all,
> > those methods start with get_ready_ep(), which will fail unless we have
> > ->state == S
On Tue, Mar 03, 2015 at 10:47:14AM -0500, Alan Stern wrote:
> @@ -1279,6 +1284,9 @@ ep0_poll (struct file *fd, poll_table *w
> struct dev_data *dev = fd->private_data;
> int mask = 0;
>
> + if (dev->state <= STATE_DEV_OPENED)
> + return
; revised patch below.
> >
> > Thanks, in contrast to the patch from Al Viro that one applies.
Translation: it applies to mainline as well as to vfs.git#gadget +
ep_config_operations patch it's incremental to.
> And as I've just tested it, it isn't complete. ep_
es actually were. It's easy enough to fix
> > >> up, though; revised patch below.
> > >
> > > Thanks, in contrast to the patch from Al Viro that one applies.
> >
> > And as I've just tested it, it isn't complete. ep_config_operations will
On Sun, Mar 08, 2015 at 02:35:25PM -0400, Alan Stern wrote:
> > FWIW, I've pushed those two fixes in vfs.git#gadget; could I have your
> > s-o-b on the ep0 part? See 2b13438 in vfs.git...
>
> Certainly.
>
> Signed-off-by: Alan Stern
Amended and pushed...
--
To unsubscribe from this list: send
nus-2; would you be OK with pulling that?
It's on
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus-2
Shortlog:
Al Viro (8):
new helper: dup_iter()
move iov_iter.c from mm/ to lib/
gadget/function/f_fs.c: close leaks
gadget/function/f_fs.c:
On Fri, Mar 13, 2015 at 03:38:17PM +1100, Stephen Rothwell wrote:
> There is also a conflict with e9eab93cc2dc ("fs: don't allow to
> complete sync iocbs through aio_complete"), though it doesn't show up
> in the resolution since I I just used the next-next tree bits. So a
> common branch contain
Assorted fixes around AIO on gadgetfs: leaks, use-after-free,
troubles caused by ->f_op flipping. Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git gadget
Shortlog:
Al Viro (8):
new helper: dup_iter()
move iov_iter.c from mm/ to lib/
gad
On Sun, Mar 15, 2015 at 01:39:21AM +0100, Alexander Holler wrote:
> Am 13.03.2015 um 17:42 schrieb Al Viro:
> > Assorted fixes around AIO on gadgetfs: leaks, use-after-free,
> > troubles caused by ->f_op flipping. Please, pull from
> > git://git.kernel.org/pub/s
On Sun, Mar 15, 2015 at 07:35:20AM +0100, Alexander Holler wrote:
> > Umm... If I'm not misparsing what you said, you are talking about the
>
> Glücklicherweise nicht. Vielleicht sollten wir es zur Abwechslung mal
> mit meiner bevorzugten Sprache versuchen.
Good. I'll probably abstain from try
On Sun, Mar 15, 2015 at 09:50:01AM +0100, Alexander Holler wrote:
> Hmm, a year ago or so I've stumbled over the fact that the owner
> might be necessary for correct entries in sysfs (that was mtd). I've
> no idea if that's true here too but it might be worse to mention it.
There are two mechanis
On Wed, Aug 07, 2019 at 12:58:21PM -0700, Matthew Wilcox wrote:
> On Wed, Aug 07, 2019 at 12:28:06PM -0700, syzbot wrote:
> > usercopy: Kernel memory exposure attempt detected from wrapped address
> > (offset 0, size 0)!
> > [ cut here ]
> > kernel BUG at mm/usercopy.c:98!
>
On Thu, Apr 05, 2018 at 12:31:11AM -0700, Christoph Hellwig wrote:
> On Thu, Apr 05, 2018 at 09:19:28AM +0200, Lars-Peter Clausen wrote:
> > On 04/05/2018 08:31 AM, Kees Cook wrote:
> > > On Wed, Apr 4, 2018 at 3:31 AM, Greg KH
> > > wrote:
> > >> Lars-Peter Clausen (2):
> > >> usb: gadget:
On Sat, May 13, 2017 at 11:05:30AM +0300, Dan Carpenter wrote:
> > + data = memdup_user(buf, len);
> > + if (unlikely(IS_ERR(data)))
>
> Don't use likely/unlikely() here. It's not a fast path.
More to the point,
#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned
long
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
37 matches
Mail list logo
