Dearly Beloved In Christ,
Please forgive me for stressing you with my predicaments as I directly
believe that you will be honest to fulfill my final wish before i die.
I am Mrs.Sophia Erick, and i was Diagnosed with Cancer about 2 years
ago, before i go for a surgery i have to do this by helping the
Orphanages home, Motherless babies home, less privileged and disable
citizens and widows around the world,
So If you are interested to fulfill my final wish by using the sum of
Eleven Million Dollars, to help them as I mentioned, kindly get back
to me for more information on how the fund will be transferred to your
account.
Warm Regards,
Sincerely Mrs. Sophia Erick.
From: Oliver Hartkopp <socketcan(a)hartkopp.net>
The read access to struct canxl_frame::len inside of a j1939 created
skbuff revealed a missing initialization of reserved and later filled
elements in struct can_frame.
This patch initializes the 8 byte CAN header with zero.
Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
Cc: Oleksij Rempel <o.rempel(a)pengutronix.de>
Link: https://lore.kernel.org/linux-can/20221104052235.GA6474@pengutronix.de
Reported-by: syzbot+d168ec0caca4697e03b1(a)syzkaller.appspotmail.com
Signed-off-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
Link: https://lore.kernel.org/all/20221104075000.105414-1-socketcan@hartkopp.net
Cc: stable(a)vger.kernel.org
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
---
net/can/j1939/main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/can/j1939/main.c b/net/can/j1939/main.c
index 144c86b0e3ff..821d4ff303b3 100644
--- a/net/can/j1939/main.c
+++ b/net/can/j1939/main.c
@@ -336,6 +336,9 @@ int j1939_send_one(struct j1939_priv *priv, struct sk_buff *skb)
/* re-claim the CAN_HDR from the SKB */
cf = skb_push(skb, J1939_CAN_HDR);
+ /* initialize header structure */
+ memset(cf, 0, J1939_CAN_HDR);
+
/* make it a full can frame again */
skb_put(skb, J1939_CAN_FTR + (8 - dlc));
--
2.35.1
On 10/16/22 19:21, Bagas Sanjaya wrote:
> On 10/16/22 03:59, Phillip Lougher wrote:
>>
>> Which identified the "squashfs: support reading fragments in readahead call"
>> patch.
>>
>> There is a race-condition introduced in that patch, which involves cache
>> releasing and reuse.
>>
>> The following diff will fix that race-condition. It would be great if
>> someone could test and verify before sending it out as a patch.
>>
>> Thanks
>>
>> Phillip
>>
>> diff --git a/fs/squashfs/file.c b/fs/squashfs/file.c
>> index e56510964b22..6cc23178e9ad 100644
>> --- a/fs/squashfs/file.c
>> +++ b/fs/squashfs/file.c
>> @@ -506,8 +506,9 @@ static int squashfs_readahead_fragment(struct page **page,
>> squashfs_i(inode)->fragment_size);
>> struct squashfs_sb_info *msblk = inode->i_sb->s_fs_info;
>> unsigned int n, mask = (1 << (msblk->block_log - PAGE_SHIFT)) - 1;
>> + int error = buffer->error;
>>
>> - if (buffer->error)
>> + if (error)
>> goto out;
>>
>> expected += squashfs_i(inode)->fragment_offset;
>> @@ -529,7 +530,7 @@ static int squashfs_readahead_fragment(struct page **page,
>>
>> out:
>> squashfs_cache_put(buffer);
>> - return buffer->error;
>> + return error;
>> }
>>
>> static void squashfs_readahead(struct readahead_control *ractl)
>>
>
> No Verneed warnings so far. However, I need to test for a longer time
> (a day) to check if any warnings are reported.
>
> Thanks.
>
Also, since this regression is also found on linux-6.0.y stable branch,
don't forget to Cc stable list.
Thanks.
--
An old man doll... just what I always wanted! - Clara
#regzbot ^introduced 2139619bcad7ac44cc8f6f749089120594056613
Over at https://lore.kernel.org/linux-riscv/Yz80ewHKTPI5Rvuz@spud/T/#ebde47064434d4… it is reported that 2139619bcad7ac44cc8f6f749089120594056613 regresses userspace (openjdk) on riscv64.
This commit has already been released in v6.0 kernel upstream, but has also been included in the stable patch series all the way back to v4.19.y
There is a proposed fix for this at https://lore.kernel.org/linux-riscv/20220915193702.2201018-1-abrestic@rivos… which has not yet been merged upstream or in stable series.
Please review and merge above proposed fix, or please revert 2139619bcad7ac44cc8f6f749089120594056613 to stop the regression spreading to all the distributions.
In Ubuntu this regression will be tracked as https://bugs.launchpad.net/bugs/+bug/1992484
-------- Forwarded Message --------
Subject: Re: [PATCH] riscv: mmap with PROT_WRITE but no PROT_READ is invalid
Date: Thu, 6 Oct 2022 22:20:02 +0300
From: Eva Kotova <nyandarknessgirl(a)gmail.com>
Reply-To: PH7PR14MB559464DBDD310E755F5B21E8CEDC9(a)PH7PR14MB5594.namprd14.prod.outlook.com
To: coelacanthus(a)outlook.com
CC: c141028(a)gmail.com, dramforever(a)live.com, linux-riscv(a)lists.infradead.org, palmer(a)dabbelt.com, xc-tan(a)outlook.com
On Tue, 31 May 2022 00:56:52 PDT (-0700), coelacanthus(a)outlook.com wrote:
> As mentioned in Table 4.5 in RISC-V spec Volume 2 Section 4.3, write
> but not read is "Reserved for future use.". For now, they are not valid.
> In the current code, -wx is marked as invalid, but -w- is not marked
> as invalid.
This patch breaks OpenJDK/Java on RISC-V, as it tries to create a w-only
protective page:
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 4096 bytes for failed to
allocate memory for PaX check.
# An error report file with more information is saved as:
# /root/hs_err_pid107.log
I bisected to this commit since on Linux 5.19+ java no longer works.
Perhaps some fallback should be implemented, to prevent userspace
breakage. It is currently documented, that at least on i386 PROT_WRITE
mappings imply PROT_READ (See man mmap(2) NOTES), this would be a good
place to start.
Best regards,
Eva
_______________________________________________
linux-riscv mailing list
linux-riscv(a)lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
On Wed, 26 Oct 2022 20:24:38 +0900 NARIBAYASHI Akira <a.naribayashi(a)fujitsu.com> wrote:
> Depending on the memory configuration, isolate_freepages_block() may
> scan pages out of the target range and causes panic.
>
> The problem is that pfn as argument of fast_isolate_around() could
> be out of the target range. Therefore we should consider the case
> where pfn < start_pfn, and also the case where end_pfn < pfn.
>
> This problem should have been addressd by the commit 6e2b7044c199
> ("mm, compaction: make fast_isolate_freepages() stay within zone")
> but there was an oversight.
>
> Case1: pfn < start_pfn
>
> <at memory compaction for node Y>
> | node X's zone | node Y's zone
> +-----------------+------------------------------...
> pageblock ^ ^ ^
> +-----------+-----------+-----------+-----------+...
> ^ ^ ^
> ^ ^ end_pfn
> ^ start_pfn = cc->zone->zone_start_pfn
> pfn
> <---------> scanned range by "Scan After"
>
> Case2: end_pfn < pfn
>
> <at memory compaction for node X>
> | node X's zone | node Y's zone
> +-----------------+------------------------------...
> pageblock ^ ^ ^
> +-----------+-----------+-----------+-----------+...
> ^ ^ ^
> ^ ^ pfn
> ^ end_pfn
> start_pfn
> <---------> scanned range by "Scan Before"
>
> It seems that there is no good reason to skip nr_isolated pages
> just after given pfn. So let perform simple scan from start to end
> instead of dividing the scan into "Before" and "After".
Under what circumstances will this panic occur? I assume those
circumstnces are pretty rare, give that 6e2b7044c1992 was nearly two
years ago.
Did you consider the desirability of backporting this fix into earlier
kernels?
A problem about modprobe ingenic-drm failed is triggered with the following
log given:
[ 303.561088] Error: Driver 'ingenic-ipu' is already registered, aborting...
modprobe: ERROR: could not insert 'ingenic_drm': Device or resource busy
The reason is that ingenic_drm_init() returns platform_driver_register()
directly without checking its return value, if platform_driver_register()
failed, it returns without unregistering ingenic_ipu_driver_ptr, resulting
the ingenic-drm can never be installed later.
A simple call graph is shown as below:
ingenic_drm_init()
platform_driver_register() # ingenic_ipu_driver_ptr are registered
platform_driver_register()
driver_register()
bus_add_driver()
priv = kzalloc(...) # OOM happened
# return without unregister ingenic_ipu_driver_ptr
Fixing this problem by checking the return value of
platform_driver_register() and do platform_unregister_drivers() if
error happened.
Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
Signed-off-by: Yuan Can <yuancan(a)huawei.com>
Cc: stable(a)vger.kernel.org
---
Changes in v2:
- Add missing Cc: stable(a)vger.kernel.org
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index ab0515d2c420..4499a04f7c13 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -1629,7 +1629,11 @@ static int ingenic_drm_init(void)
return err;
}
- return platform_driver_register(&ingenic_drm_driver);
+ err = platform_driver_register(&ingenic_drm_driver);
+ if (IS_ENABLED(CONFIG_DRM_INGENIC_IPU) && err)
+ platform_driver_unregister(ingenic_ipu_driver_ptr);
+
+ return err;
}
module_init(ingenic_drm_init);
--
2.17.1
From: xiongxin <xiongxin(a)kylinos.cn>
The actual calculation formula in the code below is:
max_size = (count - (size + PAGES_FOR_IO)) / 2
- 2 * DIV_ROUND_UP(reserved_size, PAGE_SIZE);
But function comments are written differently, the comment is wrong?
By the way, what exactly do the "/ 2" and "2 *" mean?
Cc: stable(a)vger.kernel.org
Signed-off-by: xiongxin <xiongxin(a)kylinos.cn>
---
kernel/power/snapshot.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
index 2a406753af90..c20ca5fb9adc 100644
--- a/kernel/power/snapshot.c
+++ b/kernel/power/snapshot.c
@@ -1723,8 +1723,8 @@ static unsigned long minimum_image_size(unsigned long saveable)
* /sys/power/reserved_size, respectively). To make this happen, we compute the
* total number of available page frames and allocate at least
*
- * ([page frames total] + PAGES_FOR_IO + [metadata pages]) / 2
- * + 2 * DIV_ROUND_UP(reserved_size, PAGE_SIZE)
+ * ([page frames total] - PAGES_FOR_IO - [metadata pages]) / 2
+ * - 2 * DIV_ROUND_UP(reserved_size, PAGE_SIZE)
*
* of them, which corresponds to the maximum size of a hibernation image.
*
--
2.25.1