in virtiofs is that
>>>> GFP_ATOMIC is used even when the allocation occurs in a kworker context.
>>>> Therefore the last patch uses GFP_NOFS for the allocation of both sg
>>>> array and bounce buffer when initiated by the kworker. For more details,
>>>> p
ed for fuse request and reply in virtio-fs. If the length
> of out_args[0].size is not limited, the number of scatterlist used to
> map the fuse request may be greater than the queue size of virtio-queue
> and the fuse request may hang forever.
I'm currently also totally busy and didn't carefully check, but isn't
there something missing that limits fc->max_write/fc->max_read?
Thanks,
Bernd
On 1/10/24 02:16, Hou Tao wrote:
Hi,
On 1/9/2024 9:11 PM, Bernd Schubert wrote:
On 1/3/24 11:59, Hou Tao wrote:
From: Hou Tao
When trying to insert a 10MB kernel module kept in a virtiofs with cache
disabled, the following warning was reported:
[ cut here
27;t it make sense to use kvm_alloc_array/kvfree in that function?
Thanks,
Bernd
10MB is passed to copy_args_to_argbuf(), kmalloc() is called in turn
with len=10MB, and triggers the warning in __alloc_pages():
WARN_ON_ONCE_GFP(order > MAX_ORDER, gfp)).
A feasible solution is to limit the value
-l
45
> $ grep "= {0};" kernel/ -nr | wc -l
> 4
$ egrep -nr "=[[:space:]]*{[[:space:]]*0[[:space:]]*};" kernel | wc -l
8
MfG,
Bernd
--
Bernd Petrovitsch Email : be...@petrovitsch.priv.at
There is NO CLOUD, just other people's computers. - FSFE
LUGA : http://www.luga.at
{
>
> For drivers/accessibility/speakup/keyhelp.c:18:static u_short masks[] = { 32,
> 16, 8, 4, 2, 1 };
Looking at the examples: Just s/^static /static const / in the lines
reported by the grep's above and see if it compiles (and save space)?
MfG,
Bernd
--
Bernd Petro
n Vortex86DX.
There are some real/true PC104 boards left -
still in production - with boards (though
they tend to loose features like
"memory-mapping over the ISA-bus").
One is a - according to /proc/cpuinfo - a
"Intel(R) Atom(TM) CPU E3825 @ 1.33GHz".
Sry, I cannot ge
distributions out there that pull all necessary in?
> Introducing the build breakage is annoying.
Yes, update/install the necessary package to fix it.
MfG,
Bernd
--
Bernd Petrovitsch Email : be...@petrovitsch.priv.at
There is no cloud, just other people computers. - FSFE
LUGA : http://www.luga.at
to
https://wiki.debian.org/X32Port ?
[...]
MfG,
Bernd
--
Bernd Petrovitsch Email : be...@petrovitsch.priv.at
There is no cloud, just other people computers. - FSFE
LUGA : http://www.luga.at
On Sat, 2021-01-02 at 12:26 +0100, Sedat Dilek wrote:
> On Sat, Jan 2, 2021 at 12:05 PM Bernd Petrovitsch
> wrote:
> > On Sat, 2021-01-02 at 10:13 +0100, Sedat Dilek wrote:
> > [...]
> > > To be honest I wondered why there were no more reports on this.
> >
>
bashrc "fixes" the
$PATH).
MfG,
Bernd
--
Bernd Petrovitsch Email : be...@petrovitsch.priv.at
There is no cloud, just other people computers. - FSFE
LUGA : http://www.luga.at
sign.
Kind regards,
Bernd
--
Bernd Petrovitsch Email : be...@petrovitsch.priv.at
There is no cloud, just other people computers. - FSFE
LUGA : http://www.luga.at
has
to wait on ovl_i_mutex.
Philosopher E calls exec, and wants to take down_write(exec_mutex_lock), has to
wait for Philosopher D.
Now Philosopher A wakes up from his sleep, and wants to take
down_read(exec_mutex_lock), but due
to fairness reasons, he has to wait until Philosopher E gets and releases his
write lock again.
If Philosopher A is now blocked, we have a deadlock, right?
Bernd.
> Linus
>
r_unlock:
> - kcmp_unlock(&task1->signal->exec_update_mutex,
> - &task2->signal->exec_update_mutex);
> + kcmp_unlock(&task1->signal->exec_update_lock,
> + &task2->signal->exec_update_lock);
> err:
> put_task_struct(task1);
> put_task_struct(task2);
Thanks
Bernd.
ACKed?).
close() on a socket calls shutdown() automatically (unless
the shutdown() has been already called).
The timeout which you're application runs into
applies after shutting down/closing the connection.
MfG,
Bernd
--
Bernd Petrovitsch Email : be...@petrovi
Just set the SO_REUSEADDR socket option on the listening socket.
> not help. Now I think I found the problem.
Then solve it.
> Please do have a look at the code. It looks like the SIGHUP is sent to the
> server not on close or exit, but on the connect instead.
Too lazy to save and unco
$(READELF)")
>>> +GAS_STATUS = $($(CONFIG_SHELL) $(srctree)/arch/ia64/scripts/check-gas
>>> "$(CC)" "$(OBJDUMP)")
>>> +KBUILD_CPPFLAGS += $($(CONFIG_SHELL)
>>> $(srctree)/arch/ia64/scripts/toolchain-flags "$(CC)" "$(OBJDUMP)"
>>> "$(READELF)")
>>
>>
>>
>> These changes look wrong to me.
>>
>> $($(CONFIG_SHELL)-> $(shell $(CONFIG_SHELL)
>>
>
> From the above text, I understand as follows:
Did you actually *test* that (expecially) these lines work
afterwards as good as before?
> That my proposed change:
> $(shell $(src...)-> $($(CONFIG_SHELL) $(src...)
>
> is WRONG
Yup, as it's in a Makefile and that's a Makefile construct.
> and in the next line he suggested the required correction.
> That being:
> $($(CONFIG_SHELL)-> $(shell $(CONFIG_SHELL)
Such stuff should generally not be needed as the to-be-used
shell can be set in Makefiles via a "SHELL = " assignment
(defaulting to /bin/sh - what else;-).
Flags for the shell can BTW set with ".SHELLFLAGS = ".
So please
-) learn basic "Makefile" + "make" before brainlessly patching
a Makefile.
-) actually testy your changes to make sure the patch didn't
broke anything
-) and - last but not least - check if there isn't a shell
already set (and which).
MfG,
Bernd
--
There is no cloud, just other people computers.
-- https://static.fsf.org/nosvn/stickers/thereisnocloud.svg
pEpkey.asc
Description: application/pgp-keys
📩 Salut. Ich hoffe, dir geht es ebenso gut wie mir.
https://bit.ly/3ju8TyT
Bernd Weber
9/6/2020 6:16:29 PM
Boots Retail USA, Inc. is a member of Walgreens Boots Alliance. This e-mail
(including any attachments) is confidential and may be privileged or otherwise
protected. It may be
> two config options.
> What analysis can be done to narrow down the root cause?
> Any example of reference could be helpful to understand.
I haven't checked the date of the older kernel but Spectre+
Meltdown mitigation costs a lot (20%-30% speed IIRC, out
of the top of my head).
On Fri, Jul 17, 2020 at 3:22 AM Phillip Lougher
wrote:
>
> On Fri, Jul 17, 2020 at 12:07 AM Andrew Morton
> wrote:
> >
> > On Tue, 14 Jul 2020 21:41:07 +0200 Bernd Amend
> > wrote:
> >
> > > Hi,
> > >
> > > With the Linux Kernel ver
dentical to the Arch Linux Kernel configuration,
build using gcc 9 and 10 on x86_64.
Best regards,
Bernd Amend
Das ist deine Chance - https://frigraddschedbe1884.blogspot.co.il/
Alles Gute und bis bald
Bernd Weber
=NEWS=
Pulisic will be big for Chelsea - boss Lampard after 2-1 win at Villa
Chelsea boss Frank Lampard backs Christian Pulisic to play
On 4/30/20 6:40 PM, Linus Torvalds wrote:
> On Thu, Apr 30, 2020 at 7:29 AM Bernd Edlinger
> wrote:
>>
>> Ah, now I see, that was of course not the intended effect,
>> but that is not where the pseudo-deadlock happens at all,
>> would returning -RESTARTNOINTR in th
Hi Linus,
On 4/30/20 3:47 PM, Linus Torvalds wrote:
> On Thu, Apr 30, 2020 at 6:39 AM Bernd Edlinger
> wrote:
>>
>> Excuse me, but what in my /proc folder there is no attr/something
>> is there a procfs equivalent of pthread_attach ?
>>
>> What exactly is &
a deadlock in
one of my test systems after OOM-stress, but I never was able
to reproduce, the umount deadlocked, then I was not able to
reboot, could be an alpha-particle of course, who knows...
Hmmm.. maybe a stupid idea:
We could keep the old deadlock-capable API,
and add a new _flag_
uot;I want to attach to pid X" and go back into its
> eventloop, or to just treat -EAGAIN as a fatal error and give up
> trying to attach to that task.
>
Yes, exactly, the point is the caller is expected to call wait in that
scenario, otherwise the -EAGAIN just repeats forever, that is an API
change, yes, but something unavoidable, and the patch tries hard to
limit it to cases where the live-lock or pseudo-dead-lock is unavoidable
anyway.
Bernd.
On 4/29/20 9:26 PM, Jann Horn wrote:
> On Wed, Apr 29, 2020 at 9:23 PM Bernd Edlinger
> wrote:
>> On 4/29/20 7:58 PM, Linus Torvalds wrote:
>>> On Tue, Apr 28, 2020 at 4:36 PM Jann Horn wrote:
>>>>
>>>> On Wed, Apr 29, 2020 at 12:14 AM Linus
checker, fixing a bug that prevents an attack is not a good
idea, but fixing a bug that would otherwise break a virus checker
would be a good thing.
By the way, all other attempts to fix it look much more dangerous
than my initially proposed patch, you know the one you hated, but
it does work and does not look overly complicated either.
What was the reason why that cannot be done this way?
Thanks,
Bernd.
Das ist unvorstellbar! http://dvcvhksp.Sefton158.xyz/index
___
Wiederschauen
Bernd Weber
;>
>> if the compiler supports that notation
>>
>
> That patch as it stands will work with D64838, as it is adding support
> for the GNU fallthrough attribute.
>
> However, I assume that all of the /* fall through */ comments will need
> to be converted to
x32 binaries now and then (in unpredictable ways) too.
MfG,
Bernd--
"I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong."
Hi all!
On 28/07/2019 22:08, Matteo Croce wrote:
[...]
> I get this build error with 5.3-rc2"
>
> # make
> arch/arm64/Makefile:58: gcc not found, check CROSS_COMPILE_COMPAT. Stop.
- Install (some) gcc?!
- Fix $PATH so that (some) gcc can be found?!
MfG,
Bernd
--
, Upload: 4.01 Mbit/s
With this patch:Download: 36.23 Mbit/s, Upload: 17.61 Mbit/s
Signed-off-by: Oliver Zweigle
Signed-off-by: Bernd Eckstein <3ernd.eckst...@gmail.com>
---
drivers/net/usb/ipheth.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/ip
On 17/05/2019 11:25, Alexander Kapshuk wrote:
> On Fri, May 17, 2019 at 11:58 AM Bernd Petrovitsch
> wrote:
>>
>> On 17/05/2019 10:16, Alexander Kapshuk wrote:
>> [...]
>>> The 'xargs' '-r' flag is a GNU extension.
>>> If POS
;for' loop instead of as part
> of a pipeline along with 'grep' to generate the desired output:
> sed '/\/'$m'/!d;s:^kernel/: :' modules.order modules.builtin
sed "/\/${m}/!d;s/^kernel\// /" modules.order modules.builtin
MfG,
Bernd
--
Bernd Petrovitsch Email : be...@petrovitsch.priv.at
LUGA : http://www.luga.at
ich makes select wait) is now no longer consistent with
the test that follows (which makes select wake up):
this is not waking up, when rng_init < 2 and entropy_bits < 128
/* should we wake readers? */
if (entropy_bits >= random_read_wakeup_bits &&
wq_has_sleeper(&random_read_wait)) {
wake_up_interruptible(&random_read_wait);
kill_fasync(&fasync, SIGIO, POLL_IN);
}
but a select will be immediately satisfied if
if (ENTROPY_BITS(&input_pool) >= random_read_wakeup_bits)
mask |= EPOLLIN | EPOLLRDNORM;
those need to match, or the select behaves erratically.
if (crng_ready() && ENTROPY_BITS(&input_pool) >=
random_read_wakeup_bits)
mask |= EPOLLIN | EPOLLRDNORM;
would behave consistently.
Bernd.
d_wakeup_bits=64,
while actually, the goal I want to achive (the readability condition in
random_pool keep true at all times) it would only require
num = extract_entropy(r, &buf, 32, 16, crng_ready()
? (random_read_wakeup_bits + 7) / 8 : 0);
The former version just leaves a few bits more in the input_pool, but the
reason why I did it is just to be simple (save one add), and ensure the
ready condition in the random_pool does not change due to the CRNG reseeding.
What might also be changed, is inject random data from the CRNG once that
is initialized to the blocking_pool, to make that device start up faster, or
at least not make it much worse than before. As I said, I did not regard
that as absolutely necessary, but might change my mind about that.
I would be happy to hear your thoughts, how to proceed.
Bernd.
on entropy which would make /dev/random block
unexpectedly.
Signed-off-by: Bernd Edlinger
---
v4 makes the /dev/random block until the input_pool has
reached 128 bits of entropy at least once. Now make
everything depend on input_pool.initialized.
Additionally fixed a potential issue with jiffies
quot;, x);
for (i=0; i + n = input_pool.initialized && crng_ready()
> + ? extract_entropy_user(&blocking_pool, buf, nbytes)
Thanks (for your patience :-)
Bernd.
on entropy which would make /dev/random block
unexpectedly.
Signed-off-by: Bernd Edlinger
---
v4 makes the /dev/random block until the input_pool has
reached 128 bits of entropy at least once. Now make
everything depend on input_pool.initialized.
Additionally fixed a potential issue with jiffies
On 2/17/19 9:44 AM, Bernd Edlinger wrote:
>
> + if (crng_ready() && !blocking_pool.initialized &&
After some more debugging I realize that blocking_pool.initialized
is true after 128 bits of input entropy, but that is only 80 bits
credited, due to the as
and select on /dev/random wait until
the crng is fully initialized and the blocking_pool is
also initialized which means that more than 128 bits of
entopy have been accumulated in the blocking_pool.
Signed-off-by: Bernd Edlinger
---
The v3 version waits much longer than the v2 version,
since
n
from the blocking_pool so the blocking_pool's entropy_count
effectively stays at zero, when this path is taken.
That you don't like, right?
You propose to disable the second path until the first path
has pulled 128 bits into the blocking_pool, right?
Thanks
Bernd.
and select on /dev/random wait until
the crng is fully initialized.
Signed-off-by: Bernd Edlinger
---
v2: Fixed one white space in the code.
Also added some more details about the problem
to the commit message.
---
drivers/char/random.c | 10 +++---
1 file changed, 7 insertions(+), 3
On 2/15/19 2:47 AM, Bernd Edlinger wrote:
> while (1) {
> - n = extract_entropy_user(&blocking_pool, buf, nbytes);
> + n = crng_ready()
> + ? extract_entropy_user(&blocking_pool, buf, nbytes)
> + : 0
Reading from /dev/random may return data while the getrandom
syscall is still blocking.
Those bytes are not yet cryptographically secure.
Make read and select for reading on /dev/random wait until
the crng is fully initialized.
Signed-off-by: Bernd Edlinger
---
drivers/char/random.c | 10
On 1/25/19 1:24 PM, Bernd Edlinger wrote:
> On 1/25/19 12:39 PM, Miguel Ojeda wrote:
>> On Fri, Jan 25, 2019 at 11:58 AM Arnd Bergmann wrote:
>>>
>>> On Fri, Jan 25, 2019 at 11:43 AM Laura Abbott wrote:
>>>>
>>>> Commit bee20031772a ("di
;>> Signed-off-by: Laura Abbott
>>> ---
>>> This is RFC because it feels ugly. I went ahead and did the obvious fixup
>>> but it's worth discussing if we're going to end up with an explosion or
>>> if there's a better way to handle this in one
hared keys,
by returning EOPNOTSUPP. However, pairwise keys are
still handled by hardware which works just fine.
Signed-off-by: Bernd Edlinger
---
drivers/net/wireless/ralink/rt2x00/rt61pci.c | 93 ++--
1 file changed, 4 insertions(+), 89 deletions(-)
diff --git a/d
This patch moves the clearing of rtlpriv->link_info.num_rx_inperiod in
rtl_watchdog_wq_callback a few lines down.
This is necessary since it is still used in the "AP off" detection
code block. Moved clearing of rtlpriv->link_info.num_rx_inperiod
as well for consistency.
Sign
beacon was received.
Fixed a style nit in rtl8723e_dm_init_rate_adaptive_mask.
Signed-off-by: Bernd Edlinger
---
v2: Improve patch description.
v3: Improve patch description, mention that dm.undec_sm_pwdb
is not used when no beacon received.
Make the title fit in one line.
v4: Try to fix the line
: Bernd Edlinger
---
v2: Improved patch description.
v3: Make the title fit in one line.
v4: Try to fix the line endings the message body.
---
drivers/net/wireless/realtek/rtlwifi/core.c | 2 ++
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c | 8
2 files changed, 10 insertions
power-save mode").
Previously the power save mode was only active rarely and
only for a short time so that the problem was not noticeable.
Signed-off-by: Bernd Edlinger
---
v2: Adjust the defaults of swlps and fwlps module
parameters to match the firmware capabilities instead of removing
-activated once a firmware
update is available.
v3: Make the title of each patch fit in one line.
v4: Try to fix the line endings the message body.
Which is an exchange server issue.
The patch does not change at all.
Bernd Edlinger (4):
rtl8723ae: Take the FW LPS mode handling out
On 1/8/19 6:27 PM, Kalle Valo wrote:
> Bernd Edlinger writes:
>
>> This appears to trigger a firmware bug and causes severe
>> problems with rtl8723ae PCI devices.
>>
>> When the power save mode is activated for longer periods
>> of time the firmware stop
On 08/01/2019 12:37, Jiri Kosina wrote:
> On Tue, 8 Jan 2019, Bernd Petrovitsch wrote:
>
>> Shouldn't the application use e.g. mlock()/ to guarantee no page
>> faults in the first place?
>
> Calling mincore() on pages you've just mlock()ed is sort
ll try to do some kind of prefaulting,
> possibly in a loop. There might be somebody trying to make sure something is
> out
Isn't that racy by design as the pages may get flushed out after the check?
Shouldn't the application use e.g. mlock()/ to guarantee no page
faults in the f
This patch moves the clearing of rtlpriv->link_info.num_rx_inperiod in
rtl_watchdog_wq_callback a few lines down.
This is necessary since it is still used in the "AP off" detection
code block. Moved clearing of rtlpriv->link_info.num_rx_inperiod
as well for consistency.
Sign
beacon was received.
Fixed a style nit in rtl8723e_dm_init_rate_adaptive_mask.
Signed-off-by: Bernd Edlinger
---
v2: Improve patch description.
v3: Improve patch description, mention that dm.undec_sm_pwdb
is not used when no beacon received.
Make the title fit in one line.
---
.../net/wireless
: Bernd Edlinger
---
v2: Improved patch description.
v3: Make the title fit in one line.
---
drivers/net/wireless/realtek/rtlwifi/core.c | 2 ++
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c | 8
2 files changed, 10 insertions(+)
diff --git a/drivers/net/wireless/realtek
power-save mode").
Previously the power save mode was only active rarely and
only for a short time so that the problem was not noticeable.
Signed-off-by: Bernd Edlinger
---
v2: Adjust the defaults of swlps and fwlps module
parameters to match the firmware capabilities instead of removing
-activated once a firmware
update is available.
v3: Make the title of each patch fit in one line.
Bernd Edlinger (4):
rtl8723ae: Take the FW LPS mode handling out
rtl8723ae: Dont use old data for input gain control
rtl8723ae: Re-introduce the adaptive rate control
rtlwifi: Don't
rtl8723e_dm_refresh_rate_adaptive_mask
This function was present in a previous version of the code base,
it works just fine for me -- as long as it is not using stale data.
Fixed a style nit in rtl8723e_dm_init_rate_adaptive_mask.
Signed-off-by: Bernd Edlinger
---
.../net/wireless/realtek
rtlpriv->link_info.num_rx_inperiod in rtl_watchdog_wq_callback a few lines
down
This is necessary since it is still used in the "AP off" detection
code block. Moved clearing of rtlpriv->link_info.num_rx_inperiod
as well for consistency.
Signed-off-by: Bernd Edlinger
---
driv
pre_cck_fa_state/cur_cck_fa_state in
rtl_dm_diginit.
Signed-off-by: Bernd Edlinger
---
drivers/net/wireless/realtek/rtlwifi/core.c | 2 ++
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c | 8
2 files changed, 10 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtlwifi
power-save mode").
Previously the power save mode was only active rarely and
only for a short time so that the problem was not noticeable.
Signed-off-by: Bernd Edlinger
---
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
di
-activated once a firmware
update is available.
Bernd Edlinger (4):
rtlwifi: rtl8723ae: Take the FW LPS mode handling out
rtlwifi: rtl8723ae: Don't use dm.undec_sm_pwdb for input gain control
when no beacon was received in the connected state
rtlwifi: rtl8723ae: Re-intr
ly activated when there _is_ busy traffic, the next
packet did usually wake the firmware, rarely it did freeze however.
Other things like changing the cck_packet_detection_threshold or
refresh_rate_adaptive_mask
can also kick the firmware back to life.
Hope this helps to track down the root cause of this bug.
Thanks
Bernd.
On 1/5/19 3:44 AM, Larry Finger wrote:
> On 1/4/19 6:48 AM, Bernd Edlinger wrote:
>> This appears to trigger a firmware bug and causes severe
>> problems with rtl8723ae PCI devices.
>>
>> When the power save mode is activated for longer periods
>> of time the firm
power-save mode").
Previously the power save mode was only active rarely and
only for a short time so that the problem was not noticeable.
Signed-off-by: Bernd Edlinger
---
.../net/wireless/realtek/rtlwifi/rtl8723ae/fw.c| 20
.../net/wireless/realtek/rtlwifi/rtl8723ae/fw
gain control when no beacon was received in the connected state.
This avoids sporadic "Connection to AP ... lost" errors.
Signed-off-by: Bernd Edlinger
---
drivers/net/wireless/realtek/rtlwifi/core.c | 2 ++
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/dm.c | 8
rtlpriv->link_info.num_rx_inperiod in rtl_watchdog_wq_callback a few lines
down.
This is necessary since it is still used in the "AP off" detection
code block. Moved clearing of rtlpriv->link_info.num_rx_inperiod
as well for consistency.
Signed-off-by: Bernd Edlinger
-
rtl8723ae PCI card in my laptop
against a FRITZ!Box 7590 AP -- the WiFi connection works now
very reliable for me.
Bernd Edlinger (4):
rtlwifi: rtl8723ae: Take the FW LPS mode handling out
rtlwifi: rtl8723ae: Don't use dm.undec_sm_pwdb for input gain control
when no beaco
rtl8723e_dm_refresh_rate_adaptive_mask
This function was present in a previous version of the code base,
it works just fine for me -- as long as it is not using stale data.
Fixed a style nit in rtl8723e_dm_init_rate_adaptive_mask.
Signed-off-by: Bernd Edlinger
---
.../net/wireless/realtek
gt; Are you idiots [...]
>
> Are you idiots aware that I am a lawyer[...]
>
> Are you idiots [...]
Interesting "qualities" of communication are apparently in order for
(alleged) lawyers in your part of the world.
MfG,
Bernd
PS: Sry for feeding the troll- won&#
On 14/12/2018 17:17, Rich Felker wrote:
> On Fri, Dec 14, 2018 at 03:13:10PM +0100, Bernd Petrovitsch wrote:
[..]
>> FWIW I have
>> snip
>> #if defined __x86_64__
>> # if defined __ILP32__ // x32
>> # define PRI_time_t "lld"
ace code for printf() and friends - I don't know how libc's
react to such a patch (and I don't care for the name of the macros as
long it's obviously clear for which type they are).
I assume/fear we won't get additional modifiers into the relevant
standards for libc types (as
nough hardware/systems out there that uses 64bit CPUs
(for whatever reason - if only that one can't get a 32bit CPU for that
board) but will never ever need more than 2-3 GB RAM .
MfG,
Bernd
--
Bernd Petrovitsch Email : be...@petrovitsch.priv.at
LUGA : http://www.luga.at
s, if accepted to be found in lots of publicly
accessible git repos can be not intended to be published?
I wonder what else must happen.
> public -- it is intended for those who code or wish to.
MfG,
Bernd
--
Bernd Petrovitsch Email : be...@petrovitsch.priv.at
LUGA : http://www.luga.at
pEpkey.asc
Description: application/pgp-keys
rable) rights of
your written to the company paying you (and the rest is usually not
enough to get anything revoked).
I don't see why that should be any different with GPLv2 patches for the
Kernel sent to public mailinglists with the intent of inclusion.
Please get back to the issue and
ress.
IMHO you cannot "publish" already published stuff.
MfG,
Bernd, NAL
--
Bernd Petrovitsch Email : be...@petrovitsch.priv.at
LUGA : http://www.luga.at
pEpkey.asc
Description: application/pgp-keys
Ping...
Sorry, I had actually completely forgotten about this one.
On 07/07/18 19:52, Bernd Edlinger wrote:
> The terminating NUL byte is only there because the buffer is
> allocated with kzalloc(PAGE_SIZE, GFP_KERNEL), but since the
> range-check is off-by-one, and PAGE_SIZE==PATH
server+CGI-
script for a web interface and a SNMP agent (hacked net-smtp as we had
our own configuration daemon and needed SNMP only as a transport
protocol).
[...]
MfG,
Bernd
[0]: Every byte counts and size does matter;-)
--
Bernd Petrovitsch Email : be...@petrovitsch.priv.at
LUGA : http://www.luga.at
On 07/08/18 12:41, Masahiro Yamada wrote:
> 2018-07-08 17:09 GMT+09:00 Bernd Edlinger :
>> On 07/08/18 08:31, Bernd Edlinger wrote:
>>> The next make after an oldconfig reads in the outdated
>>> include/config/auto.conf which can kill the make before
>>> it i
On 07/08/18 08:31, Bernd Edlinger wrote:
> The next make after an oldconfig reads in the outdated
> include/config/auto.conf which can kill the make before
> it is able to call the syncconfig target.
>
> $ make defconfig
> *** Default configuration is based on 'x86
void this failure.
Signed-off-by: Bernd Edlinger
---
scripts/kconfig/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index a3ac2c9..ef34275 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -62,6 +62,7 @@ PHONY +
may theoretically exceed PATH_MAX and cause a fault.
Signed-off-by: Bernd Edlinger
---
fs/kernfs/symlink.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/kernfs/symlink.c b/fs/kernfs/symlink.c
index 08ccabd..774bada 100644
--- a/fs/kernfs/symlink.c
+++ b/fs/kernfs
On 07/07/18 16:01, Greg Kroah-Hartman wrote:
> On Sat, Jul 07, 2018 at 09:41:03AM +0000, Bernd Edlinger wrote:
>> The strncpy causes a warning [-Wstringop-truncation] here,
>> which indicates that it never appends a NUL byte to the path.
>> The NUL byte is only there
returned string
will not be zero-terminated if it is exactly PATH_MAX characters.
Furthermore also the initial loop may theoretically exceed PATH_MAX
and cause a fault.
Signed-off-by: Bernd Edlinger
---
fs/kernfs/symlink.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a
returned string
will not be zero-terminated if it is exactly PATH_MAX characters.
Furthermore also the initial loop may theoretically exceed PATH_MAX
and cause a fault.
Signed-off-by: Bernd Edlinger
---
fs/kernfs/symlink.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a
ing theory is the cache might freeze before
all data is written out.
Signed-off-by: Bernd Edlinger
---
arch/arm/Kconfig| 7 +++
arch/arm/include/asm/spinlock.h | 7 +++
2 files changed, 14 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a7f8e7f..f96a
warning
> > makes sense in general as explained in mannual. Thanks!
>
> The destination should be a null terminated string eventually, but we first
> need
> to make sure src is a null terminated string.
Is there strnlen() or memchr() in the kernel?
Then check the source before copyi
ore constructive - thing: Perhaps it is more
acceptable/useful if there is a mount option which must be activated on
the backup filesystems and that is not activated anywhere else.
MfG,
Bernd
--
Bernd Petrovitsch Email : be...@petrovitsch.priv.at
LUGA : http://www.luga.at
cient.
That's the price for security as it requires proper permissions.
Or is this a root-only syscall?
MfG,
Bernd
--
Bernd Petrovitsch Email : be...@petrovitsch.priv.at
LUGA : http://www.luga.at
just wondering if it wouldn't be even more safe to use text/plain
(instead of application/octet-stream) as the default MIME type if one
wants to avoid to be misused to send viruses etc.
MfG,
Bernd
PS: Sry, for somewhat semi-off-topic
--
Bernd Petrovitsch Email :
started between v4.5 and v4.6
and prevails up to v4.14.
Using the dirty_tx before acquiring the spin lock is clearly
wrong and was first introduced with v4.6.
Fixes: e3ad57c96715 ("stmmac: review RX/TX ring management")
Signed-off-by: Bernd Edlinger
---
drivers/net/ethernet/stmi
/*
Why not get rid of the trivial wrapper function completely?
MfG,
Bernd
--
Bernd Petrovitsch Email : be...@petrovitsch.priv.at
LUGA : http://www.luga.at
o be in the
> mainline kernel. So when your driver prints "blah: foo bar error 49",
> just run a little program that converts 49 to .
Userspace can just guess if a given "49" is an errno or not ...
MfG,
Bernd
--
Bernd Petrovitsch Email : be...@petrovitsch.priv.at
LUGA : http://www.luga.at
lies
practically the rights to be able to do everything.
MfG,
Bernd
--
Bernd Petrovitsch Email : be...@petrovitsch.priv.at
LUGA : http://www.luga.at
), GFP_KERNEL);
doesn't do and the compiler doesn't complain.
And the typeof() version could be written that way today but I can't
remember seeing it (in the kernel and elsewhere).
MfG,
Bernd
--
Bernd Petrovitsch Email : be...@petrovitsch.priv.at
LUGA : http://www.luga.at
1 - 100 of 689 matches
Mail list logo
