-------------------------------
NOTE, this is the LAST 4.14.y-rc release cycle that is going to happen.
After this release, this branch will be end-of-life. You all should
have moved to the 4.19.y branch at the very least by now, as this is it,
time to stop using this one.
-------------------------------
This is the start of the stable review cycle for the 4.14.336 release.
There are 7 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed, 10 Jan 2024 14:18:47 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.336-r…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.14.336-rc1
Geert Uytterhoeven <geert+renesas(a)glider.be>
mmc: core: Cancel delayed work before releasing host
Jorge Ramirez-Ortiz <jorge(a)foundries.io>
mmc: rpmb: fixes pause retune on all RPMB partitions.
Takashi Sakamoto <o-takashi(a)sakamocchi.jp>
firewire: ohci: suppress unexpected system reboot in AMD Ryzen machines and ASM108x/VT630x PCIe cards
Ke Xiao <xiaoke(a)sangfor.com.cn>
i40e: fix use-after-free in i40e_aqc_add_filters()
Adrian Cinal <adriancinal(a)gmail.com>
net: bcmgenet: Fix FCS generation for fragmented skbuffs
Hangyu Hua <hbh25y(a)gmail.com>
net: sched: em_text: fix possible memory leak in em_text_destroy()
Siddh Raman Pant <code(a)siddh.me>
nfc: llcp_core: Hold a ref to llcp_local->dev when holding a ref to llcp_local
-------------
Diffstat:
Makefile | 4 +-
drivers/firewire/ohci.c | 51 ++++++++++++++++++++++++++
drivers/mmc/core/block.c | 7 ++--
drivers/mmc/core/host.c | 1 +
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 4 +-
drivers/net/ethernet/intel/i40e/i40e_main.c | 8 +++-
net/nfc/llcp_core.c | 39 ++++++++++++++++++--
net/sched/em_text.c | 4 +-
8 files changed, 107 insertions(+), 11 deletions(-)
Hi there,
We are excited to offer you a comprehensive email list of school districts that includes key contact information such as phone numbers, email addresses, mailing addresses, company revenue, size, and web addresses. Our databases also cover related industries such as:
* K-12 schools
* Universities
* Vocational schools and training programs
* Performing arts schools
* Fitness centers and gyms
* Child care services and providers
* Educational publishers and suppliers
If you're interested, we would be happy to provide you with relevant counts and a test file based on your specific requirements.
Thank you for your time and consideration, and please let us know if you have any questions or concerns.
Thanks,
Amelia Turner
To remove from this mailing reply with the subject line " LEAVE US".
This is a request for guidance on where is the most appropriate I should ask
for advice on how to do problem source identification on a problem with a
Linux PC which looks like it might be kernel-related. I an providing the
minimal amount of problem symptom information here that will help responders.
Simple problem statement: My PC (Gigabyte GA-H81M-S2H based) will not start
the OS (Linux MX 23.2, Debian 12, Kernel 6.2) if my PCIE GPU card (ZOTAC
nVidia GTX-1050) is installed. The start-up process hangs after Grub is
processed but before the Login screen is presented. Start-up completes
normally when the PCIE card is not installed.
Further detail:
The ZOTAC card works without issue in another PC with a different brand
motherboard.
This PC works without issue, with the ZOTAC card installed, with a different
kernel/distribution (e.g. Mint 21.2, Ubuntu 22.04, Kernel 5.15/5.19 or Windows
10).
With any Linux version installed in this PC, which uses a Via chip, operation
is subject to the issue which prevents USB 3 operation on back plane ports,
unless ‘iommu=off’ is set in grub. This might be an entirely different problem
to that associated with the presence of the PCIE card.
Who should I be seeking help/advice problem resolution from ?
Currently,the function update_port_device_state gets the usb_hub from
udev->parent by calling usb_hub_to_struct_hub.
However, in case the actconfig or the maxchild is 0, the usb_hub would
be NULL and upon further accessing to get port_dev would result in null
pointer dereference.
Fix this by introducing an if check after the usb_hub is populated.
Fixes: 83cb2604f641 ("usb: core: add sysfs entry for usb device state")
Cc: stable(a)vger.kernel.org
Signed-off-by: Udipto Goswami <quic_ugoswami(a)quicinc.com>
---
v4: Fixed minor mistakes in the comment.
v3: Re-wrote the comment for better context.
v2: Introduced comment for the if check & CC'ed stable.
drivers/usb/core/hub.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index ffd7c99e24a3..5ba1875e6bf4 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2053,9 +2053,22 @@ static void update_port_device_state(struct usb_device *udev)
if (udev->parent) {
hub = usb_hub_to_struct_hub(udev->parent);
- port_dev = hub->ports[udev->portnum - 1];
- WRITE_ONCE(port_dev->state, udev->state);
- sysfs_notify_dirent(port_dev->state_kn);
+
+ /*
+ * The Link Layer Validation System Driver (lvstest)
+ * has step to unbind the hub before running the rest
+ * of the procedure. This triggers hub_disconnect which
+ * will set the hub's maxchild to 0, further resulting
+ * usb_hub_to_struct_hub returning NULL.
+ *
+ * Add if check to avoid running into NULL pointer
+ * de-reference.
+ */
+ if (hub) {
+ port_dev = hub->ports[udev->portnum - 1];
+ WRITE_ONCE(port_dev->state, udev->state);
+ sysfs_notify_dirent(port_dev->state_kn);
+ }
}
}
--
2.17.1
Hi,
I wanted to check with you if you had a time to go through my previous
email,
Let me know your thoughts about acquiring this email list
Regards,
*Dyana *
------------------------------------------------------------------------------------------------------------------------------------
Hi,
Would you be interested in acquiring *Physicians Email & Mailing List* for
your upcoming campaigns?
*Physician Specialties*
Anesthesiologist
Ophthalmologist
Cardiologist
Optometrist
Dermatologist
Pathologist
Dentist
Pediatrician
Emergency Medicine
Psychiatrist
Family Practitioners
Psychologist
Gastroenterologist
Plastic Surgeon
General Practitioners
Podiatrist
Gynecologist
Pulmonologist
Hospitalist
Radiologist
Hematologist
Rheumatologist
Internal Medicine
Urologist
Nephrologists
Physician Assistants
Neurologist
Nurse Practitioners
Oncologist
Registered Nurses etc.
Let me know your *target audience* so that I will get back to you with more
information along with *pricing*.
If you think I should be talking to someone else, please forward this email
to the concerned person.
Looking forward to hearing from you.
Regards,
*Dyana Collins **| **Online Marketing Executive*
PWe have a responsibility to the environment
Before printing this e-mail or any other document, let's ask ourselves
whether we need a hard copy
To unsubscribe, reply with “leave out” in the subject line.
Currently,the function update_port_device_state gets the usb_hub from
udev->parent by calling usb_hub_to_struct_hub.
However, in case the actconfig or the maxchild is 0, the usb_hub would
be NULL and upon further accessing to get port_dev would result in null
pointer dereference.
Fix this by introducing an if check after the usb_hub is populated.
Fixes: 83cb2604f641 ("usb: core: add sysfs entry for usb device state")
Cc: stable(a)vger.kernel.org
Signed-off-by: Udipto Goswami <quic_ugoswami(a)quicinc.com>
---
v3: Re-wrote the comment for better context.
v2: Introduced comment for the if check & CC'ed stable.
drivers/usb/core/hub.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index ffd7c99e24a3..6b514546e59b 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2053,9 +2053,23 @@ static void update_port_device_state(struct usb_device *udev)
if (udev->parent) {
hub = usb_hub_to_struct_hub(udev->parent);
- port_dev = hub->ports[udev->portnum - 1];
- WRITE_ONCE(port_dev->state, udev->state);
- sysfs_notify_dirent(port_dev->state_kn);
+
+ /*
+ * The Link Layer Validation System Driver (lvstest)
+ * has procedure of unbinding the hub before running
+ * the rest of the procedure. This triggers
+ * hub_disconnect will set the hub's maxchild to 0.
+ * This would result usb_hub_to_struct_hub in this
+ * function to return NULL.
+ *
+ * Add if check to avoid running into NULL pointer
+ * de-reference.
+ */
+ if (hub) {
+ port_dev = hub->ports[udev->portnum - 1];
+ WRITE_ONCE(port_dev->state, udev->state);
+ sysfs_notify_dirent(port_dev->state_kn);
+ }
}
}
--
2.17.1
The patch titled
Subject: readahead: avoid multiple marked readahead pages
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
readahead-avoid-multiple-marked-readahead-pages.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Jan Kara <jack(a)suse.cz>
Subject: readahead: avoid multiple marked readahead pages
Date: Thu, 4 Jan 2024 09:58:39 +0100
ra_alloc_folio() marks a page that should trigger next round of async
readahead. However it rounds up computed index to the order of page being
allocated. This can however lead to multiple consecutive pages being
marked with readahead flag. Consider situation with index == 1, mark ==
1, order == 0. We insert order 0 page at index 1 and mark it. Then we
bump order to 1, index to 2, mark (still == 1) is rounded up to 2 so page
at index 2 is marked as well. Then we bump order to 2, index is
incremented to 4, mark gets rounded to 4 so page at index 4 is marked as
well. The fact that multiple pages get marked within a single readahead
window confuses the readahead logic and results in readahead window being
trimmed back to 1. This situation is triggered in particular when maximum
readahead window size is not a power of two (in the observed case it was
768 KB) and as a result sequential read throughput suffers.
Fix the problem by rounding 'mark' down instead of up. Because the index
is naturally aligned to 'order', we are guaranteed 'rounded mark' == index
iff 'mark' is within the page we are allocating at 'index' and thus
exactly one page is marked with readahead flag as required by the
readahead code and sequential read performance is restored.
This effectively reverts part of commit b9ff43dd2743 ("mm/readahead: Fix
readahead with large folios"). The commit changed the rounding with the
rationale:
"... we were setting the readahead flag on the folio which contains the
last byte read from the block. This is wrong because we will trigger
readahead at the end of the read without waiting to see if a subsequent
read is going to use the pages we just read."
Although this is true, the fact is this was always the case with read
sizes not aligned to folio boundaries and large folios in the page cache
just make the situation more obvious (and frequent). Also for sequential
read workloads it is better to trigger the readahead earlier rather than
later. It is true that the difference in the rounding and thus earlier
triggering of the readahead can result in reading more for semi-random
workloads. However workloads really suffering from this seem to be rare.
In particular I have verified that the workload described in commit
b9ff43dd2743 ("mm/readahead: Fix readahead with large folios") of reading
random 100k blocks from a file like:
[reader]
bs=100k
rw=randread
numjobs=1
size=64g
runtime=60s
is not impacted by the rounding change and achieves ~70MB/s in both cases.
Link: https://lkml.kernel.org/r/20240104085839.21029-1-jack@suse.cz
Fixes: b9ff43dd2743 ("mm/readahead: Fix readahead with large folios")
Signed-off-by: Jan Kara <jack(a)suse.cz>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Guo Xuenan <guoxuenan(a)huawei.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/readahead.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/readahead.c~readahead-avoid-multiple-marked-readahead-pages
+++ a/mm/readahead.c
@@ -469,7 +469,7 @@ static inline int ra_alloc_folio(struct
if (!folio)
return -ENOMEM;
- mark = round_up(mark, 1UL << order);
+ mark = round_down(mark, 1UL << order);
if (index == mark)
folio_set_readahead(folio);
err = filemap_add_folio(ractl->mapping, folio, index, gfp);
_
Patches currently in -mm which might be from jack(a)suse.cz are
readahead-avoid-multiple-marked-readahead-pages.patch