general buffer allocations.
Reference:
[1] "Open Host Controller Interface Specification for USB",
release 1.0a, Compaq, Microsoft, National Semiconductor, 1999,
pp. 16, 19, 33.
Reported-by: Guenter Roeck
Signed-off-by: Fredrik Noring
---
drivers/usb/core/hcd.c | 2 +-
d
: Fredrik Noring
---
Hi Christoph,
This patch is based on my v5.0.21 branch, with Laurentiu Tudor's other
local memory changes.
Fredrik
---
include/linux/genalloc.h | 10 +++-
lib/genalloc.c | 100 +--
2 files changed, 105 insertions(+), 5 dele
Hi Christoph,
> Can you send me the patch formally so that I can queue it up for the
> dma-mapping tree?
That patch would be detrimental to local memory devices, as previously
discussed, so I would like to suggest a much better approach, as shown below,
where allocations are aligned as required b
Hi Guenter,
> You are right, the patch below fixes the problem. I did not get the warning
> with order==5. Nevertheless, I also tested with order==8; that works as well.
>
> Thanks a lot for tracking this down!
You are welcome, and thanks for your report!
This patch series needs some redesign,
Hi Guenter,
> Thanks for the confirmation. Do you see the problem only with the
> ohci-sm501 driver or also with others ?
All are likely affected, but it depends, because I believe the problem is
that the USB subsystem runs out of memory. Please try the attached patch!
The pool assumed 4096 byte
Hi Guenter,
> I don't think I'll have time to do that anytime soon. Not that I know what
> exactly to look for in the first place.
I can confirm that there is a problem with mass storage devices and these
local memory patches.
Fredrik
Hi Guenter,
> > This patch results in usb access failures when trying to boot from the
> > sm501-usb controller on sh4 with qemu.
> >
> > usb 1-2.1: reset full-speed USB device number 4 using sm501-usb
> > sd 1:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x03
> > driverbyte=0x00
> > sd 1
Hi,
This fixes 53809751ac23 ("sscanf: don't ignore field widths for numeric
conversions"). sscanf overflows integers with simple strings such as dates.
As an example, consider
r = sscanf("20190523123456", "%4d%2d%2d%2d%2d%2d",
&year, &month, &day,
&hour, &m
Thanks Laurentiu!
> --- a/include/linux/usb/hcd.h
> +++ b/include/linux/usb/hcd.h
> @@ -216,6 +216,9 @@ struct usb_hcd {
> #define HC_IS_RUNNING(state) ((state) & __ACTIVE)
> #define HC_IS_SUSPENDED(state) ((state) & __SUSPEND)
>
> + /* allocator for HCs having local memory */
>
edrik
lib/genalloc.c: Add gen_pool_dma_zalloc() for zeroed DMA allocations
gen_pool_dma_zalloc() is a zeroed memory variant of gen_pool_dma_alloc().
Document return values of both, and indicate NULL as a "%NULL" constant.
Signed-off-by: Fredrik Noring
--- a/include/linux/genalloc.h
+
Hi Russell,
> -Original Message-
> > The initial version (marked RFC) attracted very little interest from
> > testers, or acks. I'd very much like to have some testing of it, so
> > if you want to try it out, I can provide you with a git URL, patches
> > or a combined patch.
>
> Sure! A
Fri, Jun 27, 2014 at 04:16:57PM +0000, Fredrik Noring wrote:
> > Please find below a trace that appeared once with 3.16-rc2. Perhaps it
> > is of some interest?
>
> It's not that serious... I know that the FEC ethernet driver is horrendously
> racy (I have had a patch s
Hi Russell,
> -Original Message-
> It's not that serious... I know that the FEC ethernet driver is horrendously
> racy (I have had a patch set for about the last six months which fixes some of
> its problems) but as I've had a lot of patches to deal with, and it's been
> pushed to the back
Hi Russel,
> On Thu, Jun 26, 2014 at 04:14:24PM +0100, Russell King - ARM Linux wrote:
> > That's a similar workload to the one which is mentioned in the
> > previous report. I've just set a similar transfer going, but this
> > will be a 16GB file.
>
> I've run this transfer several times, but s
David,
True. Even though there is a point in making the kernel detect and
behave consistently in this case applications (often) end up with
their own mess they cannot easily handle. A few more use cases would
now work OK but probably not enough to make the improvement worthwhile.
Thanks,
Alan,
Alan Cox wrote:
Given that 99.99% of programs don't appear to care and you materially
slow down a critical path for every read and write I'm skeptical.
I've made required_fds a struct list_head list to accommodate for
multiple fd:s (not sure that's absolutely needed though), so a coupl
Paul,
Paul Jackson wrote:
You suspected correctly - Apple Mail line wrapped it at 72 columns
(added newlines in any line going past column 72.) This makes it
impossible to apply the patch without alot of hand editing.
Of course, sorry about that. New try!
Regarding the FIXME: Marking bad fd:
Alan,
Alan Cox wrote:
The reader still has the fd open so the fd is not yet closed. This
seems
completely sane to me. Closing the *writer* fd would create an EOF
which
is the proper response.
The fd is removed from the file descriptor table, but sure the file
(as in the kernel struct fil
file_pos_write(file, pos);
fput_light(file, fput_needed);
}
+ del_required_fds(current);
return ret;
}
--- linux-2.6.19-gentoo-r5/fs/open.c2007-07-12 22:03:14.0 +0200
+++ linux-2.6.19-required-fds/fs/open.c 2007-08-12 16
19 matches
Mail list logo
