13 Aug, 2020
1 commit
-
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.Signed-off-by: Alexander A. Klimov
Signed-off-by: Andrew Morton
Reviewed-by: Kees Cook
Link: http://lkml.kernel.org/r/20200726110117.16346-1-grandmaster@al2klimov.de
Signed-off-by: Linus Torvalds
07 May, 2020
1 commit
-
Sleeping for a certain amount of time requires use of different
functions, depending on the time period.
Documentation/timers/timers-howto.rst explains when to use which
function, and also checkpatch checks for some potentially
problematic cases.So let's create a helper that automatically chooses the appropriate
sleep function -> fsleep(), for flexible sleepingIf the delay is a constant, then the compiler should be able to ensure
that the new helper doesn't create overhead. If the delay is not
constant, then the new helper can save some code.Signed-off-by: Heiner Kallweit
Signed-off-by: David S. Miller
08 Mar, 2019
1 commit
-
Sparse issues a warning:
CHECK init/calibrate.c
init/calibrate.c:271:28: warning: symbol 'calibration_delay_done' was not declared. Should it be static?The actual issue is that it's a __weak symbol that archs can override
(in fact, ARM does so), but no prototype is provided. Let's provide one
to prevent surprises.Link: http://lkml.kernel.org/r/18827.1548750938@turing-police.cc.vt.edu
Signed-off-by: Valdis Kletnieks
Reviewed-by: Andrew Morton
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
21 Jan, 2017
1 commit
-
There seems to be some misunderstanding that udelay() and friends will
always guarantee the specified delay. This is a false understanding.
When udelay() is based on CPU cycles, it can return early for many
reasons which are detailed by Linus' reply to me in a thread in 2011:http://lists.openwall.net/linux-kernel/2011/01/12/372
However, a udelay test module was created in 2014 which allows udelay()
to only be 0.5% fast, which is outside of the CPU-cycles udelay()
results I measured back in 2011, which were deemed to be in the "we
don't care" region.test_udelay() should be fixed to reflect the real allowable tolerance
on udelay(), rather than 0.5%.Cc: David Riley
Cc: John Stultz
Signed-off-by: Russell King
Signed-off-by: John Stultz
04 Aug, 2010
2 commits
-
usleep_range is a finer precision implementations of msleep
and is designed to be a drop-in replacement for udelay where
a precise sleep / busy-wait is unnecessary.Since an easy interface to hrtimers could lead to an undesired
proliferation of interrupts, we provide only a "range" API,
forcing the caller to think about an acceptable tolerance on
both ends and hopefully avoiding introducing another interrupt.INTRO
As discussed here ( http://lkml.org/lkml/2007/8/3/250 ), msleep(1) is not
precise enough for many drivers (yes, sleep precision is an unfair notion,
but consistently sleeping for ~an order of magnitude greater than requested
is worth fixing). This patch adds a usleep API so that udelay does not have
to be used. Obviously not every udelay can be replaced (those in atomic
contexts or being used for simple bitbanging come to mind), but there are
many, many examples ofmydriver_write(...)
/* Wait for hardware to latch */
udelay(100)in various drivers where a busy-wait loop is neither beneficial nor
necessary, but msleep simply does not provide enough precision and people
are using a busy-wait loop instead.CONCERNS FROM THE RFC
Why is udelay a problem / necessary? Most callers of udelay are in device/
driver initialization code, which is serial...As I see it, there is only benefit to sleeping over a delay; the
notion of "refactoring" areas that use udelay was presented, but
I see usleep as the refactoring. Consider i2c, if the bus is busy,
you need to wait a bit (say 100us) before trying again, your
current options are:* udelay(100)
* msleep(1) = | COUNT
1000 | 319
500 | 414
100 | 1146
20 | 1832I am working on Android, so that is my focus for this. The following table
is a modified usleep that simply printk's the amount of time requested to
sleep; these tests were run on a kernel with udelay >= 20 --> usleep"boot" is power-on to lock screen
"power collapse" is when the power button is pushed and the device suspends
"resume" is when the power button is pushed and the lock screen is displayed
(no touchscreen events or anything, just turning on the display)
"use device" is from the unlock swipe to clicking around a bit; there is no
sd card in this phone, so fail loading music, video, cameraACTION | TOTAL NUMBER OF USLEEP CALLS | NET TIME (us)
boot | 22 | 1250
power-collapse | 9 | 1200
resume | 5 | 500
use device | 59 | 7700The most interesting category to me is the "use device" field; 7700us of
busy-wait time that could be put towards better responsiveness, or at the
least less power usage.Signed-off-by: Patrick Pannuto
Cc: apw@canonical.com
Cc: corbet@lwn.net
Cc: arjan@linux.intel.com
Cc: Randy Dunlap
Cc: Andrew Morton
Signed-off-by: Thomas Gleixner -
This reverts commit 22b8f15c2f7130bb0386f548428df2ffd4e81903 to merge
an advanced version.Signed-off-by: Thomas Gleixner
23 Jul, 2010
1 commit
-
usleep[_range] are finer precision implementations of msleep
and are designed to be drop-in replacements for udelay where
a precise sleep / busy-wait is unnecessary. They also allow
an easy interface to specify slack when a precise (ish)
wakeup is unnecessary to help minimize wakeupsSigned-off-by: Patrick Pannuto
Cc: akinobu.mita@gmail.com
Cc: sboyd@codeaurora.org
Acked-by: Arjan van de Ven
LKML-Reference:
Signed-off-by: Thomas Gleixner
24 Jun, 2008
2 commits
-
As suggested by Ingo, remove all references to tsc from init/calibrate.c
TSC is x86 specific, and using tsc in variable names in a generic file should
be avoided. lpj_tsc is now called lpj_fine, since it is related to fine tuning
of lpj value. Also tsc_rate_* is called timer_rate_*Signed-off-by: Alok N Kataria
Cc: Arjan van de Ven
Cc: Daniel Hecht
Cc: Tim Mann
Cc: Zach Amsden
Cc: Sahil Rihan
Signed-off-by: Ingo Molnar -
On the x86 platform we can use the value of tsc_khz computed during tsc
calibration to calculate the loops_per_jiffy value. Its very important
to keep the error in lpj values to minimum as any error in that may
result in kernel panic in check_timer. In virtualization environment, On
a highly overloaded host the guest delay calibration may sometimes
result in errors beyond the ~50% that timer_irq_works can handle,
resulting in the guest panicking.Does some formating changes to lpj_setup code to now have a single
printk to print the bogomips value.We do this only for the boot processor because the AP's can have
different base frequencies or the BIOS might boot a AP at a different
frequency.Signed-off-by: Alok N Kataria
Cc: Arjan van de Ven
Cc: Daniel Hecht
Cc: Tim Mann
Cc: Zach Amsden
Cc: Sahil Rihan
Signed-off-by: Ingo Molnar
05 Mar, 2008
1 commit
-
We should be able to do ndelay(some_u64), but that can cause a call to
__divdi3() to be emitted because the ndelay() macros does a divide.Fix it by switching to static inline which will force the u64 arg to be
treated as an unsigned long. udelay() takes an unsigned long arg.[bunk@kernel.org: reported m68k build breakage]
Cc: Adrian Bunk
Cc: Evgeniy Polyakov
Cc: Martin Michlmayr
Cc: Herbert Xu
Cc: Ralf Baechle
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Adrian Bunk
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
21 Jun, 2006
1 commit
-
On partitioned PPC64 systems where a partition is given 1/10 of a
processor, we have seen mdelay() delaying for 10 times longer than it
should. The reason is that the generic mdelay(n) does n delays of 1
millisecond each. However, with 1/10 of a processor, we only get a
one-millisecond timeslice every 10ms. Thus each 1 millisecond delay
loop ends up taking 10ms elapsed time.The solution is just to use the PPC64 udelay function, which uses the
timebase to ensure that the delay is based on elapsed time rather than
how much processing time the partition has been given. (Yes, the
generic mdelay uses the PPC64 udelay, but the problem is that the
start time gets reset every millisecond, and each time it gets reset
we lose another 9ms.)Signed-off-by: Anton Blanchard
Signed-off-by: Paul Mackerras
Acked-by: Andrew Morton
17 Apr, 2005
1 commit
-
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.Let it rip!
