Miroslav Benes writes:
>
> Do we still need klp_state->data member? Now that it can be easily coupled
> with shadow variables, is there a reason to preserve it?
I would say yes, it could point to e.g. some lock protecting an
associated shadow variable's usage. Or be used to conveniently pass on
Eric Biggers writes:
> On Fri, Oct 02, 2020 at 02:38:36PM +0200, Torsten Duwe wrote:
>>
>> Would some maintainer please comment on potential problems or
>> shortcomings?
>>
>
> Well, very people are experts in the Linux RNG *and* have time to review large
> patchsets, especially when three peopl
fter
initialization.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index c4b7bdbd460e..14c39608cc17 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.
ract_entropy() as well as from account() called therefrom.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 14c39608cc17..35e381be20fe 100644
--- a/drive
e specification of "reseed_interval" in NIST SP800-90A.
Thus, it's better to keep the startup health test restart logic consistent
for now.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/char/rando
that queue with automatic storage duration
in add_interrupt_randomness().
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 55e784a5a2ec..37746df53acf 100644
--- a
' to the function prologue in order to
adhere to C99 rules. Likewise, move the declaration of 's' into the
body loop, the only scope it's referenced from.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 69 ---
1 file changed, 32
n + store with the ->lock being
held.
- Make account() grab the ->lock and drop the cmpxchg-retry loop in favor
of a plain assignent.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 44 +--
1 file changed, 30 insertions(+), 14 deletions(
ed.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 243 +-
1 file changed, 124 insertions(+), 119 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 680ccc82a436..55e784a5a2ec 100644
--- a/drivers/char/random.c
+++
ropy_shift, and make it set ->warmup to
the larger of 1024 and 4 * 128 / (2^-event_entropy_shift). Adjust all
call sites accordingly.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drive
t() in order to maintain a steady flow of correctly
calculated deltas across health test resets.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index cb6441
RCT are ignored, because
- as said, the statistical power is weak and a positive outcome wouldn't
tell anything and
- it's not desirable to make the caller, i.e. add_interrupt_randomness(),
to further queue any entropy once the concurrently running APT has
signaled a successful completio
rom.
Make the latter to not dispatch any entropy to the global entropy balance
if fips_enabled is on.
[1] https://lkml.kernel.org/r/5695397.lov4wx5...@positron.chronox.de
Suggested-by: Stephan Müller
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 24 ++--
1 file c
gets initialized once before
its first usage.
Make add_interrupt_randomness call fast_pool_init_accounting() earlier:
health test functionality will get invoked before the latter's old location
and it must have been initialized by that time.
Signed-off-by: Nicolai Stange
---
drivers/char/ran
reimplemented on top of the
new API before.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index e8c86abde901..bd3774c6be4b 100644
--- a
->good_tests is > 4 and the entropy
had previously been lowered.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index bb79dcb96882..24c09ba9d
e that
- There are mechanisms in place to limit the effect in magnitude and
time.
- The watermark can never exceed the total amount of entropy collected
so far. So entropy collection at boot time would have to be terribly
efficient in order for this to matter.
- As seeding the primary_
e ->lock could eventually be obtained.
As actual health tests returning anything but health_none haven't been
implemented yet, there is no behavioural change at this point.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 78 +--
1 file chan
one
single bit. Remember that fast_pool_entropy() calculates the amount of
entropy contained in a fast_pool, based on the total number of events mixed
into it and the estimated entropy per event.
[1] https://lkml.kernel.org/r/5695397.lov4wx5...@positron.chronox.de
Suggested-by: Stephan Müller
However, in this particular case of try_to_generate_entropy(),
jitter is desired and invoking queue_entropy() with its buffer locking etc.
from the timer callback could potentially contribute to that.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 42 +
the failure thresholds to the now slightly smaller n2 values.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 58 +--
1 file changed, 50 insertions(+), 8 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 131302cbc495
so far.
Implement the APT logic and wrap it in a new function, health_test_apt().
Invoke it from health_test_process().
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 56 +--
1 file changed, 54 insertions(+), 2 deletions(-)
diff --git a/dr
lt can then be
obtained by "shrinking" this intermediate representation back into an u8.
In total, the candidate extraction can be achieved within a sequence of
seven binops and six shifts.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 71 ---
with fips_enabled though and there's
simply no way to avoid it without violating the specs.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
ind
taken correctly taken into account
when calulating the amount of new entropy to dispatch to the pool based on
the latter's fill level.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/char/random.c b/drivers
.
As a side effect, the pool entropy watermark as tracked over the duration
of the write_pool() operation is now taken correctly taken into account
when calulating the amount of new entropy to dispatch to the pool based on
the latter's fill level.
Signed-off-by: Nicolai Stange
---
drivers
ing rid of that arch_get_random_long() call currently
found in add_interrupt_randomness(), move those arch_get_random_long()
calls in crng_reseed() into a separate loop and outside of the crng->lock.
There is no functional change.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c |
urn true on x86 if the CPU has
RDSEED support.
Yes, I know, one change per patch, but this is part of a RFC series.
Signed-off-by: Nicolai Stange
---
arch/arm64/include/asm/archrandom.h | 10 +-
arch/powerpc/include/asm/archrandom.h | 5 +
arch/s390/include/asm/archrandom.h|
ral RNG.
Make crng_reseed() bail out in FIPS mode if the input_pool provides
insufficient entropy and any of the arch_get_random_seed_long()
invocations fails: there's no statement regarding SP900-90B compliance of
arch_get_random_long() and so it can't be used as a backup.
Signed-off-b
it
will be wired up in an upcoming commit.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 52 +++
1 file changed, 52 insertions(+)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index a985ceb22c7c..ac36c56dd135 100644
--- a/drivers/
le_ctr_resolution() compare 16 successive
random_get_entropy() values and disable have_highres_cycle_ctr in case
the same value has been read two times in a row. As have_highres_cycle_ctr
will be only accessed if fips_enabled is true, make it return early in
case it's not set.
Signed-off-by: Nicolai
entropy() and __dispatch_queued_entropy_fast().
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 1945249597e0..424de1565927 100644
--- a/drivers/char/random.c
+++ b
All former call sites of credit_entropy_bits() and
credit_entropy_bits_safe() respectively have been converted to the new
dispatch_queued_entropy() API. Drop the now unused functions.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 29 +
1 file changed, 1
_bits() tp reset entropy_count to the original value
rather than zero on overflow.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 35e381be20fe..6adac462aa0d 100644
All former call sites of __credit_entropy_bits_fast() have been converted
to the new __dispatch_queued_entropy_fast() API. Drop the now unused
__credit_entropy_bits_fast().
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 14 --
1 file changed, 14 deletions(-)
diff --git a
reimplemented on top of the
new API before.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index b91d1fc08ac5..e8c86abde901 100644
--- a/drivers/char/random.c
+++ b/drivers
tes obtained from the input_pool.
Thus, in case failing arch_get_random_long()s in combination with
arch_randomness_required set became a problem in the future, it would be
better to improve the error path and simply return the unused entropy
extracted from t
("x86: Remove arch_has_random, arch_has_random_seed")
Signed-off-by: Nicolai Stange
---
arch/arm64/include/asm/archrandom.h | 25 ++---
arch/powerpc/include/asm/archrandom.h | 12 +++-
arch/s390/include/asm/archrandom.h| 14 --
ar
e().
Note that random_get_entropy() data doesn't get any entropy credit and
thus, this issue is not to be considered a bug, but more of an
inconsistency.
Fixes: d55535232c3d ("random: move rand_initialize() earlier")
Signed-off-by: Nicolai Stange
---
init/main.c | 2 +-
1 file c
pool_entropy_delta()'s nbits argument with nfrac, which used to be
a local variable and is expected to be given in units of 2^-ENTROPY_SHIFT.
Adapt the single caller, credit_entropy_bits(), accordingly.
Signed-off-by: Nicolai Stange
---
drivers/char/random.c | 19 ++-
1
is set to true, the calculation
will be terminated after the first iteration, effectively capping the input
nbits to one half of the pool size.
There is no functional change; callers with 'fast' set to true will be
introduced in a future patch.
Signed-off-by: Nicolai Stange
---
driver
Since commit 90ea1c6436d2 ("random: remove the blocking pool") the local
has_initialized in credit_entropy_bits() won't get set anymore and
the corresponding if-clause became dead code. Remove it as well as the
has_initialized variable itself from credit_entropy_bits().
Signed-
ndomness before
reseeding, but a (single) numa crng chained to the primary_crng may
produce as much as 8PB before the latter must eventually get reseeded
from the input_pool. But AFAICT, a SP800-90A conforming implementation
would still have to provide provisions for a blocking extract_crng().
seed the primary_crng.
Note that unlike it's the case with credit_entropy_bits(), the reseeding
won't be possible from within __credit_entropy_bits_fast() anymore once it
actually gets invoked with the pool lock being held in the future.
There is no functional ch
Josh Poimboeuf writes:
> On Wed, Aug 14, 2019 at 01:06:09PM +0200, Miroslav Benes wrote:
>> > Really, we should be going in the opposite direction, by creating module
>> > dependencies, like all other kernel modules do, ensuring that a module
>> > is loaded *before* we patch it. That would also
Petr Mladek writes:
> ---
> include/linux/livepatch.h | 2 ++
> kernel/livepatch/core.c | 8
> kernel/livepatch/state.c | 40 +++-
> kernel/livepatch/state.h | 9 +
> 4 files changed, 58 insertions(+), 1 deletion(-)
> create mode 10064
Petr Mladek writes:
> ---
> include/linux/livepatch.h | 15 +
> kernel/livepatch/Makefile | 2 +-
> kernel/livepatch/state.c | 83
> +++
> 3 files changed, 99 insertions(+), 1 deletion(-)
> create mode 100644 kernel/livepatch/state.c
>
> di
Hi Petr,
> this is another piece in the puzzle that helps to maintain more
> livepatches.
>
> Especially pre/post (un)patch callbacks might change a system state.
> Any newly installed livepatch has to somehow deal with system state
> modifications done be already installed livepatches.
>
> This p
: Emulate call function while updating in breakpoint
> handler
Reviewed-and-tested-by: Nicolai Stange
for the whole series. Many, many thanks to everybody involved!
I'll resend that live patching selftest once this fix here has been
merged.
Nicolai
--
SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah, HRB
21284 (AG Nürnberg)
Hi Steve,
many thanks for moving this forward!
Steven Rostedt writes:
>
> diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> index ef49517f6bb2..9160f5cc3b6d 100644
> --- a/arch/x86/kernel/ftrace.c
> +++ b/arch/x86/kernel/ftrace.c
> @@ -17,6 +17,7 @@
> #include
> #include
>
Steven Rostedt writes:
> On Mon, 29 Apr 2019 14:38:35 -0700
> Linus Torvalds wrote:
>
>> On Mon, Apr 29, 2019 at 1:30 PM Steven Rostedt wrote:
>> >
>> > The update from "call custom_trampoline" to "call iterator_trampoline"
>> > is where we have an issue.
>>
>> So it has never worked. Just t
Steven Rostedt writes:
> On Sun, 28 Apr 2019 10:41:10 -0700
> Andy Lutomirski wrote:
>
>
>> > Note that at any given point
>> > in time, there can be at most four such call insn emulations pending:
>> > namely at most one per "process", "irq", "softirq" and "nmi" context.
>> >
>>
>> That’s q
roc/cmdline still
match what would be expected when the live patch is applied.
Signed-off-by: Nicolai Stange
---
tools/testing/selftests/livepatch/Makefile | 3 +-
.../livepatch/test-livepatch-vs-ftrace.sh | 44 ++
2 files changed, 46 insertions(+), 1 deleti
rs such that nested int3 handling from e.g. irqs won't
clobber entries owned by outer instances.
Suggested-by: Steven Rostedt
Signed-off-by: Nicolai Stange
---
arch/x86/kernel/Makefile| 1 +
arch/x86/kernel/ftrace.c| 79 ++
With an upcoming patch improving x86' ftrace_int3_handler() not to simply
skip over the insn being updated, ftrace_ops_list_func() will have to get
referenced from arch/x86 code. Drop its 'static' qualifier.
Signed-off-by: Nicolai Stange
---
kernel/trace/ftrace.c | 8
1
7;s always run in process context and won't ever see a non-zero ->depth
value.
Finally, add the necessary bits to asm-offsets for making struct
ftrace_int3_stack accessible from assembly.
Suggested-by: Steven Rostedt
Signed-off-by: Nicolai Stange
---
arch/x86/include/asm/thread_info.h | 1
read_info for passing the
(adjusted) ->ip values from ftrace_int3_handler() to the stubs,
- provide one stub for each of the two possible jump targets and hardcode
those,
- add the live patching selftest.
Thanks,
Nicolai
Nicolai Stange (4):
x86/thread_info: introduce ->ftrace_int3_stac
Steven Rostedt writes:
> On Tue, 23 Apr 2019 20:15:49 +0200
> Nicolai Stange wrote:
>> Steven Rostedt writes:
>> > For 32 bit, we could add 4 variables on the thread_info and make 4
>> > trampolines, one for each context (normal, softirq, irq and NMI), and
>>
Hi Steven,
many thanks for having a look!
Steven Rostedt writes:
> I just found this in my Inbox, and this looks to be a legit issue.
>
> On Thu, 26 Jul 2018 12:40:29 +0200
> Nicolai Stange wrote:
>
> You still working on this?
Yes, this still needs to get fixed somehow,
Linus Torvalds writes:
> So in order to use it as a signal, first you have to first scrub the
> cache (because if the page was already there, there's no signal at
> all), and then for the signal to be as useful as possible, you're also
> going to want to try to get out more than one bit of info
Michael Ellerman writes:
> Joe Lawrence writes:
>> From: Nicolai Stange
>>
>> The ppc64 specific implementation of the reliable stacktracer,
>> save_stack_trace_tsk_reliable(), bails out and reports an "unreliable
>> trace" whenever it finds an except
Joe Lawrence writes:
> On Fri, Jan 11, 2019 at 08:51:54AM +0100, Nicolai Stange wrote:
>> Joe Lawrence writes:
>>
>> > On Fri, Jan 11, 2019 at 01:00:38AM +0100, Nicolai Stange wrote:
>
> [ ... snip ... ]
>
>> >> For testing, could you try wh
Joe Lawrence writes:
> On Fri, Jan 11, 2019 at 01:00:38AM +0100, Nicolai Stange wrote:
>> Hi Joe,
>>
>> Joe Lawrence writes:
>>
>> > tl;dr: On ppc64le, what is top-most stack frame for scheduled tasks
>> >about?
>>
>> If I'
Hi Joe,
Joe Lawrence writes:
> tl;dr: On ppc64le, what is top-most stack frame for scheduled tasks
>about?
If I'm reading the code in _switch() correctly, the first frame is
completely uninitialized except for the pointer back to the caller's
stack frame.
For completeness: _switch() sa
with run_sync().
To extend that ordering to also include ftrace_int3_call_trampoline, make
ftrace_int3_handler() disable interrupts within the iret frame returning to
it.
Store the original EFLAGS.IF into %r11's MSB which, because it represents
a kernel address, is redundant. Make ftrace_int3_call_trampoline resto
l in other contexts as well.
Thanks for your comments!
Nicolai
Nicolai Stange (1):
x86/ftrace: make ftrace_int3_handler() not to skip fops invocation
arch/x86/kernel/ftrace.c| 48 --
arch/x86/kernel/ftrace_64.S | 56 ++
Julia Lawall writes:
> On Fri, 30 Mar 2018, Nicolai Stange wrote:
>
>> Julia Lawall writes:
>>
>> > On Thu, 29 Mar 2018, Fabio Estevam wrote:
>> >
>> >> Hi Julia,
>> >>
>> >> On Thu, Mar 29, 2018 at 4:12 PM, Julia
Julia Lawall writes:
> On Thu, 29 Mar 2018, Fabio Estevam wrote:
>
>> Hi Julia,
>>
>> On Thu, Mar 29, 2018 at 4:12 PM, Julia Lawall wrote:
>> > Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE
>> > for debugfs files.
>> >
>> > Semantic patch information:
>> > Rationale: DEFINE
E(hdrincl);
This breaks the chain in the sense that the compiler is not allowed
to replace subsequent reads from hdrincl with reloads from inet->hdrincl.
Fixes: 8f659a03a0ba ("net: ipv4: fix for a race condition in raw_sendmsg")
Signed-off-by: Nicolai Stange
---
Compile-tested onl
Hi Stefano,
Stefano Brivio writes:
> On Tue, 2 Jan 2018 17:30:20 +0100
> Nicolai Stange wrote:
>
>> [...]
>>
>> diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
>> index 5b9bd5c33d9d..e84290c28c0c 100644
>> --- a/net/ipv4/raw.c
>> +++ b/net/i
int hdrincl = READ_ONCE(__hdrincl);
This breaks the chain in the sense that the compiler is not allowed
to replace subsequent reads from hdrincl with reloads from inet->hdrincl.
Fixes: 8f659a03a0ba ("net: ipv4: fix for a race condition in raw_sendmsg")
Signed-off-by: Nicolai S
n this happens, hrtimer_interrupt()
> skips calling the hrtimer handler (since it's early) and the
> apic is programmed to fire in the next microsecond.
Exactly.
> On further research I saw that Nicolai tried to fix a very similar
> problem last year:
>
> commit 1a9e4c564ab174e53ed8
Currently, debugfs_real_fops() is annotated with a
__must_hold(&debugfs_srcu) sparse annotation.
With the conversion of the SRCU based protection of users against
concurrent file removals to a per-file refcount based scheme, this becomes
wrong.
Drop this annotation.
Signed-off-by: Nic
)
Signed-off-by: Nicolai Stange
---
fs/debugfs/file.c | 106 ++
1 file changed, 50 insertions(+), 56 deletions(-)
diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 08511678b782..d3a972b45ff0 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/fi
Convert all calls to the now obsolete debugfs_use_file_start() and
debugfs_use_file_finish() to the new debugfs_file_get() and
debugfs_file_put() API.
Fixes: 49d200deaa68 ("debugfs: prevent access to removed files' private
data")
Signed-off-by: Nicolai Stang
Purge the SRCU based file removal race protection in favour of the new,
refcount based debugfs_file_get()/debugfs_file_put() API.
Fixes: 49d200deaa68 ("debugfs: prevent access to removed files' private
data")
Signed-off-by: Nicolai Stange
---
fs/debugfs/fi
ta.
A struct debugfs_fsdata gets allocated at file creation and freed from the
newly intoduced ->d_release().
Finally, move the implementation of debugfs_real_fops() out of the public
debugfs header such that struct debugfs_fsdata's declaration can be kept
private.
Signed-off-by: Nicolai Stange
-
ish() will get converted
to the new debugfs_file_get() and debugfs_file_put() by followup patches.
Fixes: 49d200deaa68 ("debugfs: prevent access to removed files' private
data")
Reported-by: Johannes Berg
Signed-off-by: Nicolai Stange
---
fs/debugfs/file.c | 48 ++
The full proxies' fops implemented by debugfs happen to be the only
offenders. Fix them up by moving their debugfs_real_fops() calls past those
to debugfs_file_get().
full_proxy_release() is special as it doesn't invoke debugfs_file_get() at
all. Leave it alone for now.
Signed-off-by: N
_file_get() has grown
from -EIO to -EIO and -ENOMEM. Make open_proxy_open() and full_proxy_open()
pass the -ENOMEM onwards to their callers.
Signed-off-by: Nicolai Stange
---
fs/debugfs/file.c | 55 ++-
fs/debugfs/inode.c| 36 +-
...@sipsolutions.net
[2]
https://lkml.kernel.org/r/CAOjnSCYGprej+vEEsSXwr=wo+ewle2d6shqytpp-dfpq3pm...@mail.gmail.com
Nicolai Stange (8):
debugfs: add support for more elaborate ->d_fsdata
debugfs: implement per-file removal protection
debugfs: debugfs_real_fops(): drop __must_hol
Bjorn Helgaas writes:
> On Mon, Sep 11, 2017 at 04:55:11AM -0700, Greg Kroah-Hartman wrote:
>> On Mon, Sep 11, 2017 at 09:45:41AM +0200, Nicolai Stange wrote:
>> > Quote from Documentation/filesystems/sysfs.txt:
>> >
>> > show() must not use snprin
lieve, a false positive due to the
quotation marks in the title.
Thanks,
Nicolai
Nicolai Stange (3):
PCI: fix race condition with driver_override
PCI: don't use snprintf() in driver_override_show()
driver core: platform: Don't read past the end of "driver_override"
("PCI: Don't read past the
end of sysfs "driver_override" buffer") from Sasha Levin.
Fixes: 3d713e0e382e ("driver core: platform: add device binding path
'driver_override'")
Cc: sta...@vger.kernel.org # v3.17+
Signed-off-by: Nicolai Stange
---
dr
with driver_override") from Adrian Salido.
Fixes: 782a985d7af2 ("PCI: Introduce new device binding path using
pci_dev.driver_override")
Cc: sta...@vger.kernel.org # v3.16+
Signed-off-by: Nicolai Stange
---
drivers/pci/pci-sysfs.c | 11 +--
1 file changed, 9 insertions(+), 2 deleti
style fix only and there's no change in functionality.
Signed-off-by: Nicolai Stange
---
drivers/pci/pci-sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 8e075ea2743e..43f7fbede448 100644
--- a/drivers/pci/p
Joe Lawrence writes:
> On 08/18/2017 10:04 AM, Petr Mladek wrote:
>> On Fri 2017-08-18 15:44:29, Nicolai Stange wrote:
>>> Joe Lawrence writes:
>>>
>>>
>>>> +
>>>> +/**
>>>> + * klp_shadow_get() - retrieve a shadow var
Joe Lawrence writes:
> +
> +/**
> + * klp_shadow_get() - retrieve a shadow variable data pointer
> + * @obj: pointer to parent object
> + * @id: data identifier
> + *
> + * Return: the shadow variable data element, NULL on failure.
> + */
> +void *klp_shadow_get(void *obj, unsig
ta.
A struct debugfs_fsdata gets allocated at file creation and freed from the
newly intoduced ->d_release().
Finally, move the implementation of debugfs_real_fops() out of the public
debugfs header such that struct debugfs_fsdata's declaration can be kept
private.
Signed-off-by: Nicolai Stange
-
The full proxies' fops implemented by debugfs happen to be the only
offenders. Fix them up by moving their debugfs_real_fops() calls past those
to debugfs_file_get().
full_proxy_release() is special as it doesn't invoke debugfs_file_get() at
all. Leave it alone for now.
Signed-off-by: N
and add memory barriers
where needed. Given the lack of proper benchmarking, that debugfs fops
aren't performance critical and that we've already got a potential
allocation/deallocation pair anyway, the added code complexity might be
highly questionable though.
_file_get() has grown
from -EIO to -EIO and -ENOMEM. Make open_proxy_open() and full_proxy_open()
pass the -ENOMEM onwards to their callers.
Signed-off-by: Nicolai Stange
---
fs/debugfs/file.c | 55 ++-
fs/debugfs/inode.c| 36 +-
ish() will get converted
to the new debugfs_file_get() and debugfs_file_put() by followup patches.
Fixes: 49d200deaa68 ("debugfs: prevent access to removed files' private
data")
Reported-by: Johannes Berg
Signed-off-by: Nicolai Stange
---
fs/debugfs/file.c | 48 ++
)
Signed-off-by: Nicolai Stange
---
fs/debugfs/file.c | 106 ++
1 file changed, 50 insertions(+), 56 deletions(-)
diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 3bc3e2e69f80..ebf5b2faf91c 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/fi
Convert all calls to the now obsolete debugfs_use_file_start() and
debugfs_use_file_finish() to the new debugfs_file_get() and
debugfs_file_put() API.
Fixes: 49d200deaa68 ("debugfs: prevent access to removed files' private
data")
Signed-off-by: Nicolai Stang
Currently, debugfs_real_fops() is annotated with a
__must_hold(&debugfs_srcu) sparse annotation.
With the conversion of the SRCU based protection of users against
concurrent file removals to a per-file refcount based scheme, this becomes
wrong.
Drop this annotation.
Signed-off-by: Nic
Purge the SRCU based file removal race protection in favour of the new,
refcount based debugfs_file_get()/debugfs_file_put() API.
Fixes: 49d200deaa68 ("debugfs: prevent access to removed files' private
data")
Signed-off-by: Nicolai Stange
---
fs/debugfs/fi
lp out resetting ->d_fsdata"
because this can wipe out another debugfs_file_get()'s achievements.
Nicolai Stange (9):
debugfs: add support for more elaborate ->d_fsdata
debugfs: implement per-file removal protection
debugfs: debugfs_real_fops(): drop __must_hold sparse annotati
On Tue, Apr 18 2017, Johannes Berg wrote:
> On Sun, 2017-04-16 at 11:51 +0200, Nicolai Stange wrote:
>>
>> +++ b/fs/debugfs/file.c
>> @@ -53,6 +53,7 @@ const struct file_operations
>> *debugfs_real_fops(const struct file *filp)
>> {
>> struct debugfs
Hi Xiaolong,
I'm encountering some difficulties running the reproducer, see below.
Any help is very welcome!
On Tue, Apr 18 2017, kernel test robot wrote:
> [ 45.772683] BUG: unable to handle kernel NULL pointer dereference at
> 0010
> [ 45.772697] IP: __debugfs_remove+0x5c/0x
1 - 100 of 577 matches
Mail list logo
