Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 03 9月, 2008 10 次提交
  3. 02 9月, 2008 3 次提交
  5. 01 9月, 2008 2 次提交
  7. 30 8月, 2008 5 次提交
  9. 29 8月, 2008 12 次提交
  11. 28 8月, 2008 8 次提交
    • S
      [CIFS] Turn off Unicode during session establishment for plaintext authentication · c76da9da
      由 Steve French 提交于 
      LANMAN session setup did not support Unicode (after session setup, unicode can
still be used though).

Fixes samba bug# 5319

CC: Jeff Layton <jlayton@redhat.com>
CC: Stable Kernel <stable@vger.kernel.org>
Signed-off-by: NSteve French <sfrench@us.ibm.com>
      c76da9da
    • S
      [CIFS] update cifs change log · 2e655021
      由 Steve French 提交于 
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      2e655021
    • J
      cifs: fix O_APPEND on directio mounts · 838726c4
      由 Jeff Layton 提交于 
      The direct I/O write codepath for CIFS is done through
cifs_user_write(). That function does not currently call
generic_write_checks() so the file position isn't being properly set
when the file is opened with O_APPEND.  It's also not doing the other
"normal" checks that should be done for a write call.

The problem is currently that when you open a file with O_APPEND on a
mount with the directio mount option, the file position is set to the
beginning of the file. This makes any subsequent writes clobber the data
in the file starting at the beginning.

This seems to fix the problem in cursory testing. It is, however
important to note that NFS disallows the combination of
(O_DIRECT|O_APPEND). If my understanding is correct, the concern is
races with multiple clients appending to a file clobbering each others'
data. Since the write model for CIFS and NFS is pretty similar in this
regard, CIFS is probably subject to the same sort of races. What's
unclear to me is why this is a particular problem with O_DIRECT and not
with buffered writes...

Regardless, disallowing O_APPEND on an entire mount is probably not
reasonable, so we'll probably just have to deal with it and reevaluate
this flag combination when we get proper support for O_DIRECT. In the
meantime this patch at least fixes the existing problem.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Cc: Stable Tree <stable@kernel.org>
Signed-off-by: NSteve French <sfrench@us.ibm.com>
      838726c4
    • P
      sched: rt-bandwidth accounting fix · cc2991cf
      由 Peter Zijlstra 提交于 
      It fixes an accounting bug where we would continue accumulating runtime
even though the bandwidth control is disabled. This would lead to very long
throttle periods once bandwidth control gets turned on again.
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cc2991cf
    • M
      Blackfin arch: Fix PM building on BF52x: No ROTWE on BF52x, add USBWE · d310fb4b
      由 Michael Hennerich 提交于 
      Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NBryan Wu <cooloney@kernel.org>
      d310fb4b
    • V
      Blackfin arch: sram: use 'unsigned long' for irqflags · 226a6ec3
      由 Vegard Nossum 提交于 
      Using just 'unsigned' will make flags an unsigned int. While this is
arguably not an error on blackfin where sizeof(int) == sizeof(long),
the patch is still justified on the grounds of principle.

The patch was generated using the Coccinelle semantic patch framework.

Cc: Julia Lawall <julia@diku.dk>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com>
Signed-off-by: NMike Frysinger <vapier.adi@gmail.com>
Signed-off-by: NBryan Wu <cooloney@kernel.org>
      226a6ec3
    • J
      sched: fix sched_rt_rq_enqueue() resched idle · f3ade837
      由 John Blackwood 提交于 
      When sysctl_sched_rt_runtime is set to something other than -1 and the
CONFIG_RT_GROUP_SCHED kernel parameter is NOT enabled, we get into a state
where we see one or more CPUs idling forvever even though there are
real-time
tasks in their rt runqueue that are able to run (no longer throttled).

The sequence is:

- A real-time task is running when the timer sets the rt runqueue
    to throttled, and the rt task is resched_task()ed and switched
    out, and idle is switched in since there are no non-rt tasks to
    run on that cpu.

- Eventually the do_sched_rt_period_timer() runs and un-throttles
    the rt runqueue, but we just exit the timer interrupt and go back
    to executing the idle task in the idle loop forever.

If we change the sched_rt_rq_enqueue() routine to use some of the code
from the CONFIG_RT_GROUP_SCHED enabled version of this same routine and
resched_task() the currently executing task (idle in our case) if it is
a lower priority task than the higher rt task in the now un-throttled
runqueue, the problem is no longer observed.
Signed-off-by: NJohn Blackwood <john.blackwood@ccur.com>
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f3ade837
    • J
      i2c: Prevent log spam on some DVB adapters · 4329cf86
      由 Jean Delvare 提交于 
      Some DVB adapters do not support the special I2C transaction that we
use for probing purposes. There's no point in logging this event, as
there's nothing the user can do and in general there is no actual
problem. So, degrade one of these messages to a debug message, and
move the other one around so that it is only printed on bogus drivers.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NUwe Bugla <uwe.bugla@gmx.de>
      4329cf86
反馈
建议 客服 返回
顶部