Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 18 4月, 2016 9 次提交
  3. 14 4月, 2016 8 次提交
  5. 07 4月, 2016 3 次提交
  7. 06 4月, 2016 3 次提交
  9. 05 4月, 2016 1 次提交
    • K
      mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros · 09cbfeaf
      由 Kirill A. Shutemov 提交于 
      PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time
ago with promise that one day it will be possible to implement page
cache with bigger chunks than PAGE_SIZE.

This promise never materialized.  And unlikely will.

We have many places where PAGE_CACHE_SIZE assumed to be equal to
PAGE_SIZE.  And it's constant source of confusion on whether
PAGE_CACHE_* or PAGE_* constant should be used in a particular case,
especially on the border between fs and mm.

Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
breakage to be doable.

Let's stop pretending that pages in page cache are special.  They are
not.

The changes are pretty straight-forward:

 - <foo> << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;

 - <foo> >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;

 - PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};

 - page_cache_get() -> get_page();

 - page_cache_release() -> put_page();

This patch contains automated changes generated with coccinelle using
script below.  For some reason, coccinelle doesn't patch header files.
I've called spatch for them manually.

The only adjustment after coccinelle is revert of changes to
PAGE_CAHCE_ALIGN definition: we are going to drop it later.

There are few places in the code where coccinelle didn't reach.  I'll
fix them manually in a separate patch.  Comments and documentation also
will be addressed with the separate patch.

virtual patch

@@
expression E;
@@
- E << (PAGE_CACHE_SHIFT - PAGE_SHIFT)
+ E

@@
expression E;
@@
- E >> (PAGE_CACHE_SHIFT - PAGE_SHIFT)
+ E

@@
@@
- PAGE_CACHE_SHIFT
+ PAGE_SHIFT

@@
@@
- PAGE_CACHE_SIZE
+ PAGE_SIZE

@@
@@
- PAGE_CACHE_MASK
+ PAGE_MASK

@@
expression E;
@@
- PAGE_CACHE_ALIGN(E)
+ PAGE_ALIGN(E)

@@
expression E;
@@
- page_cache_get(E)
+ get_page(E)

@@
expression E;
@@
- page_cache_release(E)
+ put_page(E)
Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: NMichal Hocko <mhocko@suse.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      09cbfeaf
  11. 04 4月, 2016 3 次提交
  13. 01 4月, 2016 3 次提交
  15. 31 3月, 2016 2 次提交
    • M
      usb: fix regression in SuperSpeed endpoint descriptor parsing · 59b9023c
      由 Mathias Nyman 提交于 
      commit b37d83a6 ("usb: Parse the new USB 3.1 SuperSpeedPlus Isoc
endpoint companion descriptor") caused a regression in 4.6-rc1 and fails
to parse SuperSpeed endpoint companion descriptors.

The new SuperSpeedPlus Isoc endpoint companion parsing code incorrectly
decreased the the remaining buffer size before comparing the size with the
expected length of the descriptor.

This lead to possible failure in reading the SuperSpeed endpoint companion
descriptor of the last endpoint, displaying a message like:

"No SuperSpeed endpoint companion for config 1 interface 0 altsetting 0
 ep 129: using minimum values"

Fix it by decreasing the size after comparing it.
Also finish all the SS endpoint companion parsing before calling SSP isoc
endpoint parsing function.

Fixes: b37d83a6Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      59b9023c
    • I
      USB: usbip: fix potential out-of-bounds write · b348d7dd
      由 Ignat Korchagin 提交于 
      Fix potential out-of-bounds write to urb->transfer_buffer
usbip handles network communication directly in the kernel. When receiving a
packet from its peer, usbip code parses headers according to protocol. As
part of this parsing urb->actual_length is filled. Since the input for
urb->actual_length comes from the network, it should be treated as untrusted.
Any entity controlling the network may put any value in the input and the
preallocated urb->transfer_buffer may not be large enough to hold the data.
Thus, the malicious entity is able to write arbitrary data to kernel memory.
Signed-off-by: NIgnat Korchagin <ignat.korchagin@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b348d7dd
  17. 30 3月, 2016 4 次提交
    • Y
      usb: renesas_usbhs: disable TX IRQ before starting TX DMAC transfer · 6490865c
      由 Yoshihiro Shimoda 提交于 
      This patch adds a code to surely disable TX IRQ of the pipe before
starting TX DMAC transfer. Otherwise, a lot of unnecessary TX IRQs
may happen in rare cases when DMAC is used.

Fixes: e73a9891 ("usb: renesas_usbhs: add DMAEngine support")
Cc: <stable@vger.kernel.org> # v3.1+
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      6490865c
    • Y
      usb: renesas_usbhs: avoid NULL pointer derefernce in usbhsf_pkt_handler() · 894f2fc4
      由 Yoshihiro Shimoda 提交于 
      When unexpected situation happened (e.g. tx/rx irq happened while
DMAC is used), the usbhsf_pkt_handler() was possible to cause NULL
pointer dereference like the followings:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 80000007 [#1] SMP ARM
Modules linked in: usb_f_acm u_serial g_serial libcomposite
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.5.0-rc6-00842-gac57066-dirty #63
Hardware name: Generic R8A7790 (Flattened Device Tree)
task: c0729c00 ti: c0724000 task.ti: c0724000
PC is at 0x0
LR is at usbhsf_pkt_handler+0xac/0x118
pc : [<00000000>]    lr : [<c03257e0>]    psr: 60000193
sp : c0725db8  ip : 00000000  fp : c0725df4
r10: 00000001  r9 : 00000193  r8 : ef3ccab4
r7 : ef3cca10  r6 : eea4586c  r5 : 00000000  r4 : ef19ceb4
r3 : 00000000  r2 : 0000009c  r1 : c0725dc4  r0 : ef19ceb4

This patch adds a condition to avoid the dereference.

Fixes: e73a9891 ("usb: renesas_usbhs: add DMAEngine support")
Cc: <stable@vger.kernel.org> # v3.1+
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      894f2fc4
    • F
      usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize · 03d27ade
      由 Felipe F. Tonello 提交于 
      buflen by default (256) is smaller than wMaxPacketSize (512) in high-speed
devices.

That caused the OUT endpoint to freeze if the host send any data packet of
length greater than 256 bytes.

This is an example dump of what happended on that enpoint:
HOST:   [DATA][Length=260][...]
DEVICE: [NAK]
HOST:   [PING]
DEVICE: [NAK]
HOST:   [PING]
DEVICE: [NAK]
...
HOST:   [PING]
DEVICE: [NAK]

This patch fixes this problem by setting the minimum usb_request's buffer size
for the OUT endpoint as its wMaxPacketSize.
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NFelipe F. Tonello <eu@felipetonello.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      03d27ade
    • A
      usb: phy: qcom-8x16: fix regulator API abuse · 7e8ac87a
      由 Arnd Bergmann 提交于 
      gcc warns about the use of regulators in phy_8x16_probe:

    drivers/usb/phy/phy-qcom-8x16-usb.c: In function 'phy_8x16_probe':
    drivers/usb/phy/phy-qcom-8x16-usb.c:284:13: error: 'regs[0].consumer' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    drivers/usb/phy/phy-qcom-8x16-usb.c:285:13: error: 'regs[1].consumer' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    drivers/usb/phy/phy-qcom-8x16-usb.c:286:12: error: 'regs[2].consumer' may be used uninitialized in this function [-Werror=maybe-uninitialized]

According to Mark Brown, this is the result of various abuses
of the PHY interfaces [1], so let's fix the driver instead.

This puts the regulator bulk data into the device structure so it
gets properly initialized and lets us call regulator_bulk_enable()
and regulator_bulk_disable() rather than open-coding them.

Setting the voltages the way the driver does is rather pointless
because for each regulator there is only one valid voltage
range, so that can just get set up in the DT. As there doesn't
seem to be any user of the newly added driver yet, we can simply
make sure the DTs are setting this up right when they get added.

I'm also fixing the handling of regulator_bulk_enable() failure.
Right now, the driver just ignores any failure, which doesn't make
sense, so I'm changing it to loudly complain (in case we actually
had a bug here) and error out.

Doing a fly-by review of the driver, I notice a couple of other
problems that I'm not addressing here:

- It really should not have been written as a USB PHY driver, but
  instead should use the PHY subsystem.

- The DT compatible string does not follow the usual conventions,
  and it should have a proper identifier in it rather than a wildcard.

- The example in the devicetree binding lists a register address
  that is the same as the actual EHCI host controller in the SoC
  as well as the otg-snps and the ci-hdrc device, which indicates
  that these are probably not even distinct devices (or all but
  one of them are wrong), and if more than one of them tries to
  request the resources correctly, they fail.

[1] https://lkml.org/lkml/2016/1/26/267Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      7e8ac87a
  19. 29 3月, 2016 4 次提交