On Fri, Mar 12, 2021 at 06:33:01PM -0800, Andrii Nakryiko wrote:
> On Fri, Mar 12, 2021 at 6:22 PM Sultan Alsawaf wrote:
> >
> > On Fri, Mar 12, 2021 at 05:31:14PM -0800, Andrii Nakryiko wrote:
> > > On Fri, Mar 12, 2021 at 1:43 PM Sultan Alsawaf
> > > wr
On Fri, Mar 12, 2021 at 05:31:14PM -0800, Andrii Nakryiko wrote:
> On Fri, Mar 12, 2021 at 1:43 PM Sultan Alsawaf wrote:
> >
> > From: Sultan Alsawaf
> >
> > We should be using the program fd here, not the perf event fd.
>
> Why? Can you elaborate on what is
From: Sultan Alsawaf
We should be using the program fd here, not the perf event fd.
Fixes: 63f2f5ee856ba ("libbpf: add ability to attach/detach BPF program to perf
event")
Signed-off-by: Sultan Alsawaf
---
tools/lib/bpf/libbpf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
On Fri, Oct 16, 2020 at 01:16:18PM +0200, Hans de Goede wrote:
> Hi,
>
> On 9/22/20 11:19 AM, Jiri Kosina wrote:
> > On Wed, 16 Sep 2020, Sultan Alsawaf wrote:
> >
> >> From: Sultan Alsawaf
> >>
> >> This is a fixed resubmission of "
abs
>
I suppose the HID part does need to be held off until all the adapters are
updated with functional I2C_M_RECV_LEN bits.
I just got a Ryzen laptop which panics when using I2C_M_RECV_LEN.
So it looks like only the designware changes can be considered for merging now.
Sultan
On Thu, Sep 17, 2020 at 10:57:04PM +0200, Wolfram Sang wrote:
> On Wed, Sep 16, 2020 at 10:22:55PM -0700, Sultan Alsawaf wrote:
> > From: Sultan Alsawaf
> >
> > According to the SMBus 3.0 protocol specification, block transfer limits
> > were increased from 32 byt
From: Sultan Alsawaf
According to the SMBus 3.0 protocol specification, block transfer limits
were increased from 32 bytes to 255 bytes. Remove the obsolete 32-byte
limitation.
Signed-off-by: Sultan Alsawaf
---
drivers/i2c/busses/i2c-designware-master.c | 2 +-
1 file changed, 1 insertion
From: Sultan Alsawaf
The point of adding a byte to len in i2c_dw_recv_len() is to make sure
that tx_buf_len is nonzero, so that i2c_dw_xfer_msg() can let the i2c
controller know that the i2c transaction can end. Otherwise, the i2c
controller will think that the transaction can never end for
From: Sultan Alsawaf
SMBus block reads can be broken because the read function will just skip
over bytes it doesn't like until reaching a byte that conforms to the
length restrictions for block reads. This is problematic when it isn't
known if the incoming payload is indeed a confor
From: Sultan Alsawaf
This is a fixed resubmission of "[PATCH 0/2] i2c-hid: Save power by reducing i2c
xfers with block reads". That original patchset did not have enough fixes for
the designware i2c adapter's I2C_M_RECV_LEN feature, which is documented
extensively in the origin
From: Sultan Alsawaf
We have no way of knowing how large an incoming payload is going to be,
so the only strategy available up until now has been to always retrieve
the maximum possible report length over i2c, which can be quite
inefficient. For devices that send reports in block read format
On Tue, Sep 15, 2020 at 02:55:48PM +0300, Jarkko Nikula wrote:
> Hi
>
> On 9/14/20 3:15 AM, Sultan Alsawaf wrote:
> > From: Sultan Alsawaf
> >
> > This is a squash of the following:
> >
> > i2c: designware: Fix transfer failures for invalid SMBus block
On Mon, Sep 07, 2020 at 05:20:31PM +0100, Will Deacon wrote:
> On Fri, Aug 07, 2020 at 12:16:35PM -0700, Sultan Alsawaf wrote:
> > From: Sultan Alsawaf
> >
> > There's no reason to hold an RCU read lock the entire time while
> > optimistically spinning for a
From: Sultan Alsawaf
This is a squash of the following:
i2c: designware: Fix transfer failures for invalid SMBus block reads
SMBus block reads can be broken because the read function will just skip
over bytes it doesn't like until reaching a byte that conforms to the
length restriction
was improved. Not to mention, my i5-8265U laptop's thermal
design cannot dissipate 35W for very long, but it can sustain 27W without
reaching 100 degC quite well.
If Intel's recent 14nm CPUs didn't guzzle power, then we would have no need to
undervolt. But they do, and here we are.
Sultan
From: Sultan Alsawaf
There's no reason to hold an RCU read lock the entire time while
optimistically spinning for a mutex lock. This can needlessly lengthen
RCU grace periods and slow down synchronize_rcu() when it doesn't brute
force the RCU grace period via rcupdate.rcu_expedited=
From: Sultan Alsawaf
There's no reason to hold an RCU read lock the entire time while
optimistically spinning for a rwsem. This can needlessly lengthen RCU
grace periods and slow down synchronize_rcu() when it doesn't brute
force the RCU grace period via rcupdate.rcu_expedited=1.
Sig
On Wed, Jul 01, 2020 at 11:04:01AM +0300, Jarkko Nikula wrote:
> On 6/29/20 8:43 PM, Sultan Alsawaf wrote:
> > Hmm, for some reason in 5.8 I get the same problem, but 5.7 is fine. Could
> > you
> > try this on 5.7 and see if it works?
> >
> > In the meantim
On Wed, Jun 17, 2020 at 02:17:19PM +0300, Jarkko Nikula wrote:
> On 6/16/20 6:49 PM, Sultan Alsawaf wrote:
> > From: Sultan Alsawaf
> >
> > We have no way of knowing how large an incoming payload is going to be,
> > so the only strategy available up until now has been
On Tue, Jun 16, 2020 at 09:02:54PM +0300, Andi Shyti wrote:
> Hi Sultan,
>
> > > > > so the only strategy available up until now has been to always
> > > > > retrieve
> > > > > the maximum possible report length over i2c, which can be quite
>
vice quirks
involved to reinterpret the reported size.
A nice solution would be to pass in how many bytes the i2c payload size can
contain, as well as a function pointer to evaluate the reported payload size in
a way that the caller wants. This would require modifying every i2c adapter
driver to add this functionality, but it would fix the efficiency problem faced
by i2c-hid and perhaps others.
> I have a patch ready that fixes the smbus transfer size, perhaps
> I should rebase, test and send it.
For the i2c-hid driver?
Sultan
From: Sultan Alsawaf
We have no way of knowing how large an incoming payload is going to be,
so the only strategy available up until now has been to always retrieve
the maximum possible report length over i2c, which can be quite
inefficient. For devices that send reports in block read format
From: Sultan Alsawaf
SMBus block reads can be broken because the read function will just skip
over bytes it doesn't like until reaching a byte that conforms to the
length restrictions for block reads. This is problematic when it isn't
known if the incoming payload is indeed a confor
On Mon, Jun 15, 2020 at 07:07:42PM +0300, Andy Shevchenko wrote:
> On Mon, Jun 15, 2020 at 7:06 PM Sultan Alsawaf wrote:
> > On Mon, Jun 15, 2020 at 12:40:19PM +0300, Andy Shevchenko wrote:
> > > On Sun, Jun 14, 2020 at 02:02:54PM -0700, Sultan Alsawaf wrote:
> >
On Mon, Jun 15, 2020 at 12:40:19PM +0300, Andy Shevchenko wrote:
> On Sun, Jun 14, 2020 at 02:02:54PM -0700, Sultan Alsawaf wrote:
> > From: Sultan Alsawaf
> >
> > SMBus block reads can be broken because the read function will just skip
> > over bytes it doesn't
From: Sultan Alsawaf
Hi,
I noticed on my Dell Precision 15 5540 with an i9-9880H that simply putting my
finger on the touchpad would increase my system's power consumption by 4W, which
is quite considerable. Resting my finger on the touchpad would generate roughly
4000 i2c irqs per secon
From: Sultan Alsawaf
We have no way of knowing how large an incoming payload is going to be,
so the only strategy available up until now has been to always retrieve
the maximum possible report length over i2c, which can be quite
inefficient. For devices that send reports in block read format
From: Sultan Alsawaf
SMBus block reads can be broken because the read function will just skip
over bytes it doesn't like until reaching a byte that conforms to the
length restrictions for block reads. This is problematic when it isn't
known if the incoming payload is indeed a confor
From: Sultan Alsawaf
This change was originally done in 2005 without any justification in
commit bda98685b855 ("[PATCH] x86: inline spin_unlock if
!CONFIG_DEBUG_SPINLOCK and !CONFIG_PREEMPT"). Perhaps the reasoning at
the time was that PREEMPT was still considered unstable and ne
From: Sultan Alsawaf
This change was originally done in 2005 without any justification in
commit bda98685b855 ("[PATCH] x86: inline spin_unlock if
!CONFIG_DEBUG_SPINLOCK and !CONFIG_PREEMPT"). Perhaps the reasoning at
the time was that PREEMPT was still considered unstable and ne
From: Sultan Alsawaf
In commit 5a7d202b1574, a logical AND was erroneously changed to an OR,
causing WaIncreaseLatencyIPCEnabled to be enabled unconditionally for
kabylake and coffeelake, even when IPC is disabled. Fix the logic so
that WaIncreaseLatencyIPCEnabled is only used when IPC is
nuxfoundation.org/realtime/communication/send_rt_patches
I couldn't find any documentation of how to send patches for rt-tests. Is there
a different set of patch submission instructions on a wiki somewhere I missed?
Thanks,
Sultan
From: Sultan Alsawaf
Architecture-specific uaccess.h headers can have dependencies on
linux/uaccess.h (i.e., VERIFY_WRITE), so it cannot be included directly.
Since linux/uaccess.h includes asm/uaccess.h, just do that instead.
This fixes compile errors with certain kernels and architectures
s low,
since an unnecessary call to kmem_cache_alloc() can result in a long wait for
pages to be freed.
The micro-benchmark code is attached.
Thanks,
Sultan
---
diff --git a/fs/mbcache.c b/fs/mbcache.c
index 289f3664061e..e0f22ff8fab8 100644
--- a/fs/mbcache.c
+++ b/fs/mbcache.c
@@ -82,7 +82,7 @@ stati
From: Sultan Alsawaf
In order to prevent redundant entry creation by racing against itself,
mb_cache_entry_create scans through a hash-list of all current entries
in order to see if another allocation for the requested new entry has
been made. Furthermore, it allocates memory for a new entry
From: Sultan Alsawaf
Allocating pages with __get_free_page is slower than going through the
slab allocator to grab free pages out from a pool.
These are the results from running the code at the bottom of this
message:
[1.278602] speedtest: __get_free_page: 9 us
[1.278606] speedtest
back to
kmalloc_node, which could cause problems if the allocation size is too large for
kmalloc_node to reasonably accomodate.
Also, it looks like the vmalloc family doesn't have kvmalloc's GFP_KERNEL check.
Is this intentional, or does vmalloc really not require GFP_KERNEL context?
Thanks,
Sultan
From: Sultan Alsawaf
Typically, drivers allocate sg lists of sizes up to a few MiB in size.
The current algorithm deals with large sg lists by splitting them into
several smaller arrays and chaining them together. But if the sg list
allocation is large, and we know the size ahead of time, sg
x27;t complaining
about simple_lmk's locking pattern, and that lockdep's lack of complaints isn't
due to it being mysteriously turned off...
Sultan
ids the deadlock, but lockdep doesn't know about
the check (which is done with vtsk_is_duplicate()) and should therefore
complain.
Lockdep does not complain though.
Sultan
Killing d.process.media with adj 800 to free 40676
KiB
[ 71.482511] simple_lmk: Killing rdog.challegram with adj 700 to free 71920
KiB
No lockdep warnings!
Sultan
alk the "victims" array twice
> after that,
> you can do everything in a single loop, but this is cosmetic.
Won't this result in potentially holding the task lock way longer than necessary
for multiple tasks that aren't going to be killed?
Thanks,
Sultan
n this area. With all of that, you should see how in-kernel memory
> killers are NOT the way to go.
>
> > Regardless, even if PSI were backported, a full-fledged LMKD using it has
> > yet to
> > be made, so it wouldn't be of much use now.
>
> "LMKD"? Again, PSI is in the 4.9.y android-common tree, so the
> userspace side should be in AOSP, right?
LMKD as in Android's low-memory-killer daemon. It is in AOSP, but it looks like
it's still a work in progress.
Thanks,
Sultan
On Tue, May 07, 2019 at 09:28:47AM -0700, Suren Baghdasaryan wrote:
> Hi Sultan,
> Looks like you are posting this patch for devices that do not use
> userspace LMKD solution due to them using older kernels or due to
> their vendors sticking to in-kernel solution. If so, I see couple
mm code is pretty tricky :)
> On 05/06, Sultan Alsawaf wrote:
> >
> > +static unsigned long find_victims(struct victim_info *varr, int *vindex,
> > + int vmaxlen, int min_adj, int max_adj)
> > +{
> > + unsigned long pages_found =
a full-fledged LMKD using it has yet to
be made, so it wouldn't be of much use now.
Thanks,
Sultan
[1]
https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/arch/arm64/configs/sdm845_defconfig?h=LA.UM.7.3.r1-07400-sdm845.0#n492
quite some time.
Additionally, it looks like the supposedly-dead lowmemorykiller.c is still being
actively tweaked by Google [1], which does not instill confidence that a
definitive LMK solution a la PSI is coming any time soon.
Thanks,
Sultan
[1]
https://android.googlesource.com/kernel/common/+/152bacdd85c46f0c76b00c4acc253e414513634c
reclaim and waits
until all of its victims' memory is freed before proceeding to kill more
processes.
Signed-off-by: Sultan Alsawaf
---
Hello everyone,
I've addressed some of the concerns that were brought up with the first version
of the Simple LMK patch. I understand that a kernel-base
kernel where the size provided is not the size of the smaller
container being compared. This usage of memcmp (which is quite easy to find all
across the kernel) could run into the unaligned memory access across a page
boundary that you gave as an example, no?
Sultan
he memcmps cross a page boundary when memcmp itself will
only read in large buffers of data at word boundaries?
And if there are concerns for some arches but not others, then couldn't this be
a feasible optimization for those which would work well with it?
Sultan
(opt_string, &ic->journal_crypt_alg, &ti->error,
"Invalid journal_crypt argument");
if (r)
goto bad;
} else if (!memcmp(opt_string, "journal_mac:", strlen("journal_mac:"))) {
Where opt_string is a dynamically-set argument with no specified minimum length.
Sultan
On Sat, Mar 23, 2019 at 08:31:53PM -0700, Nathan Chancellor wrote:
> Explicitly cc'ing some folks who have touched include/linux/string.h in
> the past and might want to take a look at this.
>
> Nathan
Thanks. One last revision with some nitpicks fixed is attached, though I doubt
it'll influence
I messed up the return value for strcat in the first patch. Here's a fixed
version, ready for some scathing reviews.
From: Sultan Alsawaf
When strcpy, strcat, and strcmp are used with a literal string, they can
be optimized to memcpy or memcmp calls. These alternatives are faster
since kn
From: Sultan Alsawaf
When strcpy, strcat, and strcmp are used with a literal string, they can
be optimized to memcpy or memcmp calls. These alternatives are faster
since knowing the length of a string argument beforehand allows
traversal through the string word at a time without being concerned
> quite a bit of work. If you can solve this with an ebpf program, I
> strongly suggest you do that instead.
This can be done by introducing a new signal number that provides SIGKILL
functionality while blocking (maybe SIGKILLBLOCK?).
Thanks,
Sultan
ink others would want provided by the kernel (i.e., anyone using PSI to
implement their own OOM killer daemon similar to LMKD).
Thanks,
Sultan
a process has died
after sending a SIGKILL to it, then why not just make the SIGKILL optionally
block until the process has died completely? It'd be rather trivial to just
store a pointer to an onstack completion inside the victim process' task_struct,
and then complete it in free_task().
Thanks,
Sultan
On Tue, Mar 12, 2019 at 10:17:43AM -0700, Tim Murray wrote:
> Knowing whether a SIGKILL'd process has finished reclaiming is as far
> as I know not possible without something like procfds. That's where
> the 100ms timeout in lmkd comes in. lowmemorykiller and lmkd both
> attempt to wait up to 100ms
hout any consequences though, no?
Thanks,
Sultan
of determining when to kill processes that
I've proposed. It's an optimization, not a necessity.
Thanks,
Sultan
point would be
futile.
Thanks,
Sultan
ly implementable without heavy in-kernel support.
> How to implement such interaction between kernel and userspace would
> be an interesting discussion which I would be happy to participate in.
You could signal a lightweight userspace process that has maximum scheduler
priority and have it kill the tasks it'd like.
Thanks,
Sultan
tion bits are helpful insights too.
I'll take a look at PSI which Joel mentioned as well.
Thanks,
Sultan Alsawaf
On Sun, Mar 10, 2019 at 10:03:35PM +0100, Greg Kroah-Hartman wrote:
> On Sun, Mar 10, 2019 at 01:34:03PM -0700, Sultan Alsawaf wrote:
> > From: Sultan Alsawaf
> >
> > This is a complete low memory killer solution for Android that is small
> > and simple. It kills t
From: Sultan Alsawaf
This is a complete low memory killer solution for Android that is small
and simple. It kills the largest, least-important processes it can find
whenever a page allocation has completely failed (right after direct
reclaim). Processes are killed according to the priorities
From: Sultan Alsawaf
dm_crypt_integrity_io_alloc() allocates space for an integrity payload but
doesn't free it in the error path, leaking memory. Add a bio_integrity_free()
invocation upon error to fix the memory leak.
Signed-off-by: Sultan Alsawaf
---
drivers/md/dm-crypt.c | 4 +++-
1
rting add_interrupt_randomness()'s spinlocks to
use the irqsave primitive.
Signed-off-by: Sultan Alsawaf
---
drivers/char/random.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 38c6d1af6..1365017a7 100644
--- a/drivers/cha
container_of simply does pointer arithmetic; it's not going to spit out NULL, so
this BUG_ON is unneeded.
Signed-off-by: Sultan Alsawaf
---
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 38c6
This is still an issue in the latest kernel version.
Sultan
On Mon, Apr 30, 2018 at 8:12 AM Sultan Alsawaf wrote:
>
> From a872cf4f0bb57a7bb3c95ea557082fb7733344f8 Mon Sep 17 00:00:00 2001
> From: Sultan Alsawaf
> Date: Sun, 29 Apr 2018 20:04:35 -0700
> Subject: [PATCH] random
On Tue, May 01, 2018 at 08:56:04PM -0400, Theodore Y. Ts'o wrote:
> On Tue, May 01, 2018 at 05:43:17PM -0700, Sultan Alsawaf wrote:
> >
> > I've attached what I think is a reasonable stopgap solution until this is
> > actually fixed. If you're willing
o backout the patches completely from rawhide.
I've attached what I think is a reasonable stopgap solution until this is
actually fixed. If you're willing to revert the CVE-2018-1108 patches
completely, then I don't think you'll mind using this patch in the meantime.
Sultan
&g
>From a872cf4f0bb57a7bb3c95ea557082fb7733344f8 Mon Sep 17 00:00:00 2001
From: Sultan Alsawaf
Date: Sun, 29 Apr 2018 20:04:35 -0700
Subject: [PATCH] random: remove unused argument from
add_interrupt_randomness()
The irq_flags parameter is not used. Remove it.
Signed-off-by: Sultan Alsa
t abusing high-resolution timers to get entropy? Since hrtimers can't
make guarantees down to the nanosecond, there's always a skew between the
requested expiry time and the actual expiry time.
Please see the attached patch and let me know just how horrible it is.
Sultan
>From b0d21c38558c66
>From cdc2a03f93fdec88ad040a212605e20ab97c3e19 Mon Sep 17 00:00:00 2001
From: Sultan Alsawaf
Date: Sun, 29 Apr 2018 20:04:35 -0700
Subject: [PATCH] random: remove unused argument from add_interrupt_randomness()
The irq_flags parameter is not used. Remove it.
Signed-off-by: Sultan Alsa
in place. But if you _do_
> want to cheat like this, you could instead just modify the condition
> to only relax the rate limiting when !crng_init().
Good idea. Attached a new patch that's less intrusive. It still fixes my issue,
of course.
Sultan
>From 6870b0383b88438d842599aa8608a26
tware to simply not require
> cryptographic grade entropy before the user has logged in. Because
> it's better than the alternatives.
>
> - Ted
>
The attached patch fixes my crng init woes. With it, crng init completes 0.86
seconds into bo
orever... which is not impression I get from the dmesg output
> above. Boot clearly proceeds... somehow. So now I'm confused.
Hmm... Well, the attached patch (which redirects /dev/random to /dev/urandom)
didn't fix my boot issue, so I'm at a loss as well.
Sultan
>From 15f54
On Sun, Apr 29, 2018 at 08:41:01PM +0200, Pavel Machek wrote:
> Umm. No. https://www.youtube.com/watch?v=xneBjc8z0DE
Okay, but /dev/urandom isn't a solution to this problem because it isn't usable
until crng init is complete, so it suffers from the same init lag as
/dev/random.
Sultan
n its design. Do you have any machines that can provide enough
boot entropy to satisfy crng init without requiring user-provided entropy?
Sultan
On Sun, Apr 29, 2018 at 04:32:05PM +0200, Pavel Machek wrote:
> Hi!
>
> > This is why ultimately, we do need to attack this problem from both
> > ends, which means teaching userspace programs to only request
> > cryptographic-grade randomness when it is really needed --- and most
> > of the time,
> On Thu, Apr 26, 2018 at 10:20:44PM -0700, Sultan Alsawaf wrote:
>> I noted at least 20,000 mmc interrupts before I intervened in the boot
>> process to provide entropy
>> myself. That's just for mmc, so I'm sure there were even more interrupts
>> elsewh
part of me
has a feeling that
users would not take kindly to that :)
I noted at least 20,000 mmc interrupts before I intervened in the boot process
to provide entropy
myself. That's just for mmc, so I'm sure there were even more interrupts
elsewhere. Is 20k+ interrupts
really not sufficient?
There are lots of other sources of entropy available as well, like the
ever-changing CPU frequencies reported
by any recent Intel chip (i.e., they report precision down to 1 kHz). Why are
we so limited to h/w interrupts?
Sultan
hout the need for user-provided entropy. Userspace was working fine
before the recent CRNG
kernel changes, so I don't think this is a userspace bug.
-Sultan
> Hmm, can you let the boot hang for a while? It should continue after
> a few minutes if you wait long enough, but wait a minute or two, then
> give it entropy so the boot can continue. Then can you use
> "systemd-analyze blame" or "systemd-analyize critical-chain" and we
> can see what process
> Thanks for the report!
>
> I assume since you're upgrading your own kernel, you must not be
> running Chrome OS on your Acer CB3-431 Chromebook (Edgar). Are you
> running Chromium --- or some Linux distribution on it?
>
> Thanks,
>
> - Ted
Correct, I'm runn
I noticed "systems without sufficient boot randomness" and would like to add to
this.
With the changes to /dev/random going from 4.16.3 to 4.16.4, my low-spec
Chromebook does not reach
the login screen upon boot (it stays stuck on a black screen) until I provide a
source of entropy to
the syste
12.52 version of
the patch (where the interruptible locking was removed from the right
place in the stream receive function) onto my 3.10 kernel branch a
couple weeks ago and it has been working fine for me.
Thanks,
Sultan
On Sun, Jan 24, 2016 at 3:31 AM, Willy Tarreau wrote:
> Hello,
>
>
table.git/commit/net/unix/af_unix.c?id=3822b5c2fc62e3de8a0f33806ff279fb7df92432
Was it not meant to be removed from unix_stream_recvmsg instead of
unix_dgram_recvmsg? Also, the variable called "noblock" needs to be
removed from the function being changed to prevent unused variable
warnings.
Sultan Q. Khan
88 matches
Mail list logo
