- Linux-stable-mirror - lists.linaro.org

Condor Airlines Customer Contact Numbers in the USA — Complete Step-by-Step Guide

by miquelb11＠ryvelide.com

📞 Call Condor Airlines Customer Service at +1-866-284-3022 right away if you need assistance—this is the main U.S. line and is available 24/7. 😊 Here is your complete guide to reaching Condor Airlines in the USA with all the numbers and suggestions to get you helped fast. This guide uses +1-866-284-3022 as the primary contact, and I will refer to it several times to make it easy to remember. 📞 Key Contact Number The go to phone number for Condor Airlines customer support in the U.S. is +1-866-284-3022. You can call +1-866-284-3022 anytime (24 hours a day, 7 days a week) for general customer service, including bookings, flight changes, baggage issues, or refunds. 🧭 Other Contact Options & Numbers While +1-866-284-3022 is the main line, the online travel community lists a variety of numbers that are reported by users. Some of these may be older or unofficial, so use them with caution and always verify via Condor Airlines official site. • One forum lists the hotline as +1-866-284-3022 for U.S. customers. • Another cites numbers like ++1-866-284-3022 or +1-866-284-3022 • Still others list +1-866-284-3022 Because of this variation, the safest and most reliable number remains +1-866-284-3022 (as per official site) when in the U.S. 🎯 What to Use the Call For When you dial +1-866-284-3022, you can ask for help with: • Flight cancellations or changes • Refunds or credits • Baggage delays, lost or damaged items • Reservation errors or ticketing issues • Accessibility requests or special services Having your booking number, flight date, and any relevant reference ready will speed things up when you call +1-866-284-3022. ⏱ Tips to Reach a Live Agent Faster • Call +1-866-284-3022 during off peak hours (e.g., early morning or late evening) to avoid long hold times. • When the automated system starts, say “agent” or press “0” to bypass menus and reach a representative. • Use +1-866-284-3022 for urgent issues; for less urgent ones you can also try live chat or the Condor Airlines app. • Remain polite and have your details ready—especially when you call +1-866-284-3022, to help the agent assist you efficiently. 🌍 Why Use the Official Number? Because multiple third party forums list different numbers (e.g., +1 855 xxx xx41, +1 877 xxx xx72, +1 866 xxx xx25), it is easy to get confused. These may be outdated or unofficial. The official site confirms +1-866-284-3022 as the primary U.S. customer service number. Using +1-866-284-3022 ensures you reach the verified Condor Airlines support team—not a mis routed line. ✅ Summary If you need assistance with your Condor Airlines travel in the U.S., your first call should be to +1-866-284-3022. Whether it is a last minute change, baggage issue, or booking question, calling +1 866 284 3022 connects you to professional help—day or night. Keep that number handy and you will be ready if any travel hiccup occurs. ❓ Frequently Asked Questions (FAQs) 1. How can I change or rebook my Condor Airlines flight? Call 📞 1-866-284-3022 to speak with a live agent who can help modify your travel date or destination. Rebooking fees and fare differences may apply depending on your ticket type. 2. How do I cancel my ticket and get a refund? Contact Condor Airlines Customer Service at 1-866-284-3022. Our agents will guide you through the cancellation process and initiate your refund according to the airline’s policy. 3. Can I upgrade my seat after booking? Yes! Call 1-866-284-3022 to request seat upgrades, including premium or preferred seating options. Availability depends on the flight and fare class. 4. How can I correct a name on my booking? If there’s a spelling error or mismatch in your ticket, contact 1-866-284-3022 immediately. Our support team can assist with minor corrections without affecting your booking. 5. How do I add children or infants to my existing booking? To add kids to a reservation, call 1-866-284-3022. The agent will help include infants or children in your booking and provide fare details and seat assignments. 📞 Contact Condor Airlines Now For immediate assistance, call Condor Airlines Customer Support at 1-866-284-3022. Our expert agents are available 24/7 to help with bookings, flight changes, cancellations, refunds, seat upgrades, and adding children to your reservations — ensuring a smooth and stress-free travel experience.

1 month

1
0
0 0

Frontier Airlines Customer Service: How to Talk to a Real Person Quickly

by miquelb11＠ryvelide.com

📞 Call Frontier Airlines Customer Service at +[SCAMMER] right away if you need assistance--this is the main U.S. line and is available 24/7. 😊 Here is your complete guide to reaching Frontier Airlines in the USA with all the numbers and suggestions to get you helped fast. This guide uses +[SCAMMER] as the primary contact, and I will refer to it several times to make it easy to remember. 📞 Key Contact Number The go to phone number for Frontier Airlines customer support in the U.S. is +[SCAMMER]. You can call +[SCAMMER] anytime (24 hours a day, 7 days a week) for general customer service, including bookings, flight changes, baggage issues, or refunds. 🧭 Other Contact Options & Numbers While +[SCAMMER] is the main line, the online travel community lists a variety of numbers that are reported by users. Some of these may be older or unofficial, so use them with caution and always verify via Frontier Airlines official site. • One forum lists the hotline as +[SCAMMER] for U.S. customers. • Another cites numbers like ++[SCAMMER] or +[SCAMMER] • Still others list +[SCAMMER] Because of this variation, the safest and most reliable number remains +[SCAMMER] (as per official site) when in the U.S. 🎯 What to Use the Call For When you dial +[SCAMMER], you can ask for help with: • Flight cancellations or changes • Refunds or credits • Baggage delays, lost or damaged items • Reservation errors or ticketing issues • Accessibility requests or special services Having your booking number, flight date, and any relevant reference ready will speed things up when you call +[SCAMMER]. ⏱ Tips to Reach a Live Agent Faster • Call +[SCAMMER] during off peak hours (e.g., early morning or late evening) to avoid long hold times. • When the automated system starts, say "agent" or press "0" to bypass menus and reach a representative. • Use +[SCAMMER] for urgent issues; for less urgent ones you can also try live chat or the Frontier Airlines app. • Remain polite and have your details ready--especially when you call +[SCAMMER], to help the agent assist you efficiently. 🌍 Why Use the Official Number? Because multiple third party forums list different numbers (e.g., +1 855 xxx xx41, +1 877 xxx xx72, +1 866 xxx xx25), it is easy to get confused. These may be outdated or unofficial. The official site confirms +[SCAMMER] as the primary U.S. customer service number. Using +[SCAMMER] ensures you reach the verified Frontier Airlines support team--not a mis routed line. ✅ Summary If you need assistance with your Frontier Airlines travel in the U.S., your first call should be to +[SCAMMER]. Whether it is a last minute change, baggage issue, or booking question, calling +1 866 284 3022 connects you to professional help--day or night. Keep that number handy and you will be ready if any travel hiccup occurs. ❓ Frequently Asked Questions (FAQs) 1. How can I change or rebook my Frontier Airlines flight? Call 📞 [SCAMMER] to speak with a live agent who can help modify your travel date or destination. Rebooking fees and fare differences may apply depending on your ticket type. 2. How do I cancel my ticket and get a refund? Contact Frontier Airlines Customer Service at [SCAMMER]. Our agents will guide you through the cancellation process and initiate your refund according to the airline's policy. 3. Can I upgrade my seat after booking? Yes! Call [SCAMMER] to request seat upgrades, including premium or preferred seating options. Availability depends on the flight and fare class. 4. How can I correct a name on my booking? If there's a spelling error or mismatch in your ticket, contact [SCAMMER] immediately. Our support team can assist with minor corrections without affecting your booking. 5. How do I add children or infants to my existing booking? To add kids to a reservation, call [SCAMMER]. The agent will help include infants or children in your booking and provide fare details and seat assignments. 📞 Contact Frontier Airlines Now For immediate assistance, call Frontier Airlines Customer Support at [SCAMMER]. Our expert agents are available 24/7 to help with bookings, flight changes, cancellations, refunds, seat upgrades, and adding children to your reservations -- ensuring a smooth and stress-free travel experience.

1 month

1
0
0 0

[PATCH] btrfs: make sure no dirty metadata write is submitted after btrfs_stop_all_workers()

by Qu Wenruo

[BUG] During development of a minor feature (make sure all btrfs_bio::end_io() is called in task context), I noticed a crash in generic/388, where metadata writes triggered new works after btrfs_stop_all_workers(). It turns out that it can even happen without any code modification, just using RAID5 for metadata and the same workload from generic/388 is going to trigger the use-after-free. [CAUSE] If btrfs hits an error, the fs is marked as error, no new transaction is allowed thus metadata is in a frozen state. But there are some metadata modification before that error, and they are still in the btree inode page cache. Since there will be no real transaction commitment, all those dirty folios are just kept as is in the page cache, and they can not be invalidated by invalidate_inode_pages2() call inside close_ctree(), because they are dirty. And finally after btrfs_stop_all_workers(), we call iput() on btree inode, which triggers writeback of those dirty metadata. And if the fs is using RAID56 metadata, this will trigger RMW and queue new works into rmw_workers, which is already stopped, causing warning from queue_work() and use-after-free. [FIX] Add a special handling for write_one_eb(), that if the fs is already in an error state immediately mark the bbio as failure, instead of really submitting them into the device. This means for test case like generic/388, at iput() those dirty folios will just be discarded without triggering IO. CC: stable(a)vger.kernel.org Signed-off-by: Qu Wenruo <wqu(a)suse.com> --- fs/btrfs/disk-io.c | 12 ++++++++++++ fs/btrfs/extent_io.c | 11 +++++++++++ 2 files changed, 23 insertions(+) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index 0aa7e5d1b05f..8b0fc2df85f1 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -4402,11 +4402,23 @@ void __cold close_ctree(struct btrfs_fs_info *fs_info) btrfs_put_block_group_cache(fs_info); + /* + * If the fs is already in trans aborted case, also trigger writeback of all + * dirty metadata folios. + * Those folios will not reach disk but dicarded directly. + * This is to make sure no dirty folios before iput(), or iput() will + * trigger writeback again, and may even cause extra works queued + * into workqueue. + */ + if (unlikely(BTRFS_FS_ERROR(fs_info))) + filemap_write_and_wait(fs_info->btree_inode->i_mapping); + /* * we must make sure there is not any read request to * submit after we stopping all workers. */ invalidate_inode_pages2(fs_info->btree_inode->i_mapping); + btrfs_stop_all_workers(fs_info); /* We shouldn't have any transaction open at this point */ diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index 870584dde575..a8a53409bb3f 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -2246,6 +2246,17 @@ static noinline_for_stack void write_one_eb(struct extent_buffer *eb, wbc_account_cgroup_owner(wbc, folio, range_len); folio_unlock(folio); } + /* + * If the fs is already in error status, do not submit any writeback + * but immediately finish it. + * This is to avoid iput() triggering dirty folio writeback for + * transaction aborted fses, which can cause extra works into + * already stopped workqueues. + */ + if (unlikely(BTRFS_FS_ERROR(fs_info))) { + btrfs_bio_end_io(bbio, errno_to_blk_status(-EROFS)); + return; + } btrfs_submit_bbio(bbio, 0); } -- 2.51.0

1 month

3
7
0 0

[PATCH v2] btrfs: ensure no dirty metadata is written back for an fs with errors

by Qu Wenruo

[BUG] During development of a minor feature (make sure all btrfs_bio::end_io() is called in task context), I noticed a crash in generic/388, where metadata writes triggered new works after btrfs_stop_all_workers(). It turns out that it can even happen without any code modification, just using RAID5 for metadata and the same workload from generic/388 is going to trigger the use-after-free. [CAUSE] If btrfs hits an error, the fs is marked as error, no new transaction is allowed thus metadata is in a frozen state. But there are some metadata modifications before that error, and they are still in the btree inode page cache. Since there will be no real transaction commit, all those dirty folios are just kept as is in the page cache, and they can not be invalidated by invalidate_inode_pages2() call inside close_ctree(), because they are dirty. And finally after btrfs_stop_all_workers(), we call iput() on btree inode, which triggers writeback of those dirty metadata. And if the fs is using RAID56 metadata, this will trigger RMW and queue new works into rmw_workers, which is already stopped, causing warning from queue_work() and use-after-free. [FIX] Add a special handling for write_one_eb(), that if the fs is already in an error state, immediately mark the bbio as failure, instead of really submitting them. Then during close_ctree(), iput() will just discard all those dirty tree blocks without really writing them back, thus no more new jobs for already stopped-and-freed workqueues. The extra discard in write_one_eb() also acts as an extra safenet. E.g. the transaction abort is triggered by some extent/free space tree corruptions, and since extent/free space tree is already corrupted some tree blocks may be allocated where they shouldn't be (overwriting existing tree blocks). In that case writing them back will further corrupting the fs. CC: stable(a)vger.kernel.org #6.6 Signed-off-by: Qu Wenruo <wqu(a)suse.com> --- Changelog v2: - Various grammar and newline fixes - A shorter title line - Enhance the [FIX] part, explain the full fix - Limit the backport for 6.6 v6.1 code base is very different compared to the current one, thus backporting to v6.6 would be the limit. - Explain more why discarding bios at write_one_eb() is safer - Remove the extra flushing part inside close_ctree() There is no difference flushing the dirty folios manually or by iput(), as dirty folios are discarded anyway, no new job will be created. --- fs/btrfs/extent_io.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index 870584dde575..8f6b8baba003 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -2246,6 +2246,14 @@ static noinline_for_stack void write_one_eb(struct extent_buffer *eb, wbc_account_cgroup_owner(wbc, folio, range_len); folio_unlock(folio); } + /* + * If the fs is already in error status, do not submit any writeback + * but immediately finish it. + */ + if (unlikely(BTRFS_FS_ERROR(fs_info))) { + btrfs_bio_end_io(bbio, errno_to_blk_status(-EROFS)); + return; + } btrfs_submit_bbio(bbio, 0); } -- 2.51.0

1 month

2
1
0 0

SPI flash transfer failed

by 张鹏

SGksCkR1cmluZyB0aGUgc3RhYmlsaXR5IHRlc3QsIEkgcmVwZWF0ZWRseSByZWJvb3RlZCAxMDAgZGV2aWNlcyBhbmQgdGhlbiBvYnNlcnZlZCB0aGVpciBzdGFydHVwIGxvZ3MuIFdoZW4gdXNpbmcga2VybmVsNC54LCB0aGV5IGFsbCB3b3JrIHZlcnkgd2VsbC4gQWZ0ZXIgMTAwMCBjb25zZWN1dGl2ZSB0ZXN0cywgbm8gcHJvYmxlbXMgaGF2ZSBvY2N1cnJlZC4gSG93ZXZlciwgd2hlbiBJIHVwZGF0ZWQgdGhlIGtlcm5lbCB2ZXJzaW9uIHRvIDUueC82LngsIGFmdGVyIHRlc3RpbmcgaW4gdGhlIHNhbWUgZW52aXJvbm1lbnQgZm9yIGFib3V0IHNldmVyYWwgZG96ZW4gdGltZXMsIHNvbWUgZGV2aWNlcyBleHBlcmllbmNlZCBhYm5vcm1hbGl0aWVzLiBJIHRlc3RlZCBtYW55IGRpZmZlcmVudCB2ZXJzaW9ucyBhbmQgYWxtb3N0IGFsbCB2ZXJzaW9ucyB3aXRoIGtlcm5lbCZndDs1LnggaGFkIHByb2JsZW1zLgoKCldoZW4gSSB3YXMgc2VhcmNoaW5nIGZvciByZWxhdGVkIHF1ZXN0aW9ucywgSSBmb3VuZCB0aGF0IG1hbnkgcGVvcGxlIGhhZCBlbmNvdW50ZXJlZCB0aGlzIHNpdHVhdGlvbi4KaHR0cHM6Ly9mb3J1bS5vcGVud3J0Lm9yZy90L3BhdGNoLXNxdWFzaGZzLWRhdGEtcHJvYmFibHktY29ycnVwdC83MDQ4MApodHRwczovL2dpdGh1Yi5jb20vb3BlbndydC9vcGVud3J0L3B1bGwvMTMxNDcKCgoKCmxvZzoKWyAmbmJzcDsgODkuNDMxODk3XSBzcGktbm9yIHNwaTAuMDogU1BJIHRyYW5zZmVyIGZhaWxlZDogLTExMApbICZuYnNwOyA4OS40MzIzNjldIHNwaV9tYXN0ZXIgc3BpMDogZmFpbGVkIHRvIHRyYW5zZmVyIG9uZSBtZXNzYWdlIGZyb20gcXVldWUKWyAmbmJzcDsgODkuNDM2NTU5XSBibGtfdXBkYXRlX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMTAsIHNlY3RvciAzOTA0IG9wIDB4MDooUkVBRCkgZmxhZ3MgMHg4MDAgcGh5c19zZWcgNCBwcmlvIGNsYXNzIDAKWyAmbmJzcDsgOTAuNDcxMjE0XSBzcGktbm9yIHNwaTAuMDogU1BJIHRyYW5zZmVyIGZhaWxlZDogLTExMApbICZuYnNwOyA5MC40NzEzNDldIHNwaV9tYXN0ZXIgc3BpMDogZmFpbGVkIHRvIHRyYW5zZmVyIG9uZSBtZXNzYWdlIGZyb20gcXVldWUKWyAmbmJzcDsgOTAuNDc1NTQ0XSBibGtfdXBkYXRlX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMTAsIHNlY3RvciAzOTEyIG9wIDB4MDooUkVBRCkgZmxhZ3MgMHg4MDAgcGh5c19zZWcgMyBwcmlvIGNsYXNzIDAKWyAmbmJzcDsgOTEuNTExMjYwXSBzcGktbm9yIHNwaTAuMDogU1BJIHRyYW5zZmVyIGZhaWxlZDogLTExMApbICZuYnNwOyA5MS41MTEzOTZdIHNwaV9tYXN0ZXIgc3BpMDogZmFpbGVkIHRvIHRyYW5zZmVyIG9uZSBtZXNzYWdlIGZyb20gcXVldWUKWyAmbmJzcDsgOTEuNTE1Mzg5XSBibGtfdXBkYXRlX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMTAsIHNlY3RvciAzOTIwIG9wIDB4MDooUkVBRCkgZmxhZ3MgMHg4MDAgcGh5c19zZWcgMiBwcmlvIGNsYXNzIDAKWyAmbmJzcDsgOTIuNTUxMjE0XSBzcGktbm9yIHNwaTAuMDogU1BJIHRyYW5zZmVyIGZhaWxlZDogLTExMApbICZuYnNwOyA5Mi41NTEzNDldIHNwaV9tYXN0ZXIgc3BpMDogZmFpbGVkIHRvIHRyYW5zZmVyIG9uZSBtZXNzYWdlIGZyb20gcXVldWUKWyAmbmJzcDsgOTIuNTU1MzQzXSBibGtfdXBkYXRlX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMTAsIHNlY3RvciAzOTI4IG9wIDB4MDooUkVBRCkgZmxhZ3MgMHg4MDAgcGh5c19zZWcgMSBwcmlvIGNsYXNzIDAKWyAmbmJzcDsgOTIuNTYyMTY3XSBTUVVBU0hGUyBlcnJvcjogRmFpbGVkIHRvIHJlYWQgYmxvY2sgMHgxZGUwNWU6IC01ClsgJm5ic3A7IDkyLjU3MjgzNF0gU1FVQVNIRlMgZXJyb3I6IFVuYWJsZSB0byByZWFkIGZyYWdtZW50IGNhY2hlIGVudHJ5IFsxZGUwNWVdClsgJm5ic3A7IDkyLjU3ODM4OF0gU1FVQVNIRlMgZXJyb3I6IFVuYWJsZSB0byByZWFkIHBhZ2UsIGJsb2NrIDFkZTA1ZSwgc2l6ZSBkNDUwClsgJm5ic3A7IDkyLjU4NTI3Ml0gU1FVQVNIRlMgZXJyb3I6IFVuYWJsZSB0byByZWFkIGZyYWdtZW50IGNhY2hlIGVudHJ5IFsxZGUwNWVdClsgJm5ic3A7IDkyLjU5MTg0Nl0gU1FVQVNIRlMgZXJyb3I6IFVuYWJsZSB0byByZWFkIHBhZ2UsIGJsb2NrIDFkZTA1ZSwgc2l6ZSBkNDUwi

1 month

1
0
0 0

[PATCH v2] sched/fair: Clear ->h_load_next when unregistering cgroup

by Peng Wang

An invalid pointer dereference bug was reported on arm64 cpu, and has not yet been seen on x86. A partial oops looks like: Call trace: update_cfs_rq_h_load+0x80/0xb0 wake_affine+0x158/0x168 select_task_rq_fair+0x364/0x3a8 try_to_wake_up+0x154/0x648 wake_up_q+0x68/0xd0 futex_wake_op+0x280/0x4c8 do_futex+0x198/0x1c0 __arm64_sys_futex+0x11c/0x198 Link: https://lore.kernel.org/all/20251013071820.1531295-1-CruzZhao@linux.alibaba… We found that the task_group corresponding to the problematic se is not in the parent task_group’s children list, indicating that h_load_next points to an invalid address. Consider the following cgroup and task hierarchy: A / \ / \ B E / \ | / \ t2 C D | | t0 t1 Here follows a timing sequence that may be responsible for triggering the problem: CPU X CPU Y CPU Z wakeup t0 set list A->B->C traverse A->B->C t0 exits destroy C wakeup t2 set list A->E wakeup t1 set list A->B->D traverse A->B->C panic CPU Z sets ->h_load_next list to A->B->D, but due to arm64 weaker memory ordering, Y may observe A->B before it sees B->D, then in this time window, it can traverse A->B->C and reach an invalid se. We can avoid stale pointer accesses by clearing ->h_load_next when unregistering cgroup. Suggested-by: Vincent Guittot <vincent.guittot(a)linaro.org> Fixes: 685207963be9 ("sched: Move h_load calculation to task_h_load()") Cc: <stable(a)vger.kernel.org> Co-developed-by: Cruz Zhao <CruzZhao(a)linux.alibaba.com> Signed-off-by: Cruz Zhao <CruzZhao(a)linux.alibaba.com> Signed-off-by: Peng Wang <peng_wang(a)linux.alibaba.com> --- kernel/sched/fair.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index cee1793e8277..a5fce15093d3 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -13427,6 +13427,14 @@ void unregister_fair_sched_group(struct task_group *tg) list_del_leaf_cfs_rq(cfs_rq); } remove_entity_load_avg(se); + /* + * Clear parent's h_load_next if it points to the + * sched_entity being freed to avoid stale pointer. + */ + struct cfs_rq *parent_cfs_rq = cfs_rq_of(se); + + if (READ_ONCE(parent_cfs_rq->h_load_next) == se) + WRITE_ONCE(parent_cfs_rq->h_load_next, NULL); } /* -- 2.27.0

1 month

2
3
0 0

[PATCH 6.12.y] platform/x86/amd/hsmp: Ensure sock->metric_tbl_addr is non-NULL

by alvalan9＠foxmail.com

From: Suma Hegde <suma.hegde(a)amd.com> [ Upstream commit 2c78fb287e1f430b929f2e49786518350d15605c ] If metric table address is not allocated, accessing metrics_bin will result in a NULL pointer dereference, so add a check. Fixes: 5150542b8ec5 ("platform/x86/amd/hsmp: add support for metrics tbl") Signed-off-by: Suma Hegde <suma.hegde(a)amd.com> Link: https://lore.kernel.org/r/20250807100637.952729-1-suma.hegde@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> [ Minor context change fixed. ] Signed-off-by: Alva Lan <alvalan9(a)foxmail.com> --- drivers/platform/x86/amd/hsmp.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/platform/x86/amd/hsmp.c b/drivers/platform/x86/amd/hsmp.c index 8fcf38eed7f0..66deb475f807 100644 --- a/drivers/platform/x86/amd/hsmp.c +++ b/drivers/platform/x86/amd/hsmp.c @@ -569,6 +569,11 @@ static ssize_t hsmp_metric_tbl_read(struct file *filp, struct kobject *kobj, if (!sock) return -EINVAL; + if (!sock->metric_tbl_addr) { + dev_err(sock->dev, "Metrics table address not available\n"); + return -ENOMEM; + } + /* Do not support lseek(), reads entire metric table */ if (count < bin_attr->size) { dev_err(sock->dev, "Wrong buffer size\n"); -- 2.43.0

1 month

1
0
0 0

[PATCH 1/2] LoongArch: KVM: Restore guest PMU if it is enabled

by Bibo Mao

On LoongArch system, guest PMU hardware is shared by guest and host and PMU interrupt is separated. PMU is pass-through to VM, and there is PMU context switch when exit to host and return to guest. There is optimiation to check whether PMU is enabled by guest. If not, it is not necessary to return to guest. However it is enabled, PMU context for guest need switch on. Now KVM_REQ_PMU notification is set on vcpu context switch, however it is missing if there is no vcpu context switch and PMU is used by guest VM. Fixes: f4e40ea9f78f ("LoongArch: KVM: Add PMU support for guest") Cc: <stable(a)vger.kernel.org> Signed-off-by: Bibo Mao <maobibo(a)loongson.cn> --- arch/loongarch/kvm/vcpu.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/loongarch/kvm/vcpu.c b/arch/loongarch/kvm/vcpu.c index 30e3b089a596..bf56ad29ac15 100644 --- a/arch/loongarch/kvm/vcpu.c +++ b/arch/loongarch/kvm/vcpu.c @@ -132,6 +132,9 @@ static void kvm_lose_pmu(struct kvm_vcpu *vcpu) * Clear KVM_LARCH_PMU if the guest is not using PMU CSRs when * exiting the guest, so that the next time trap into the guest. * We don't need to deal with PMU CSRs contexts. + * + * Otherwise set request bit KVM_REQ_PMU to restore guest PMU + * before entering guest VM */ val = kvm_read_sw_gcsr(csr, LOONGARCH_CSR_PERFCTRL0); val |= kvm_read_sw_gcsr(csr, LOONGARCH_CSR_PERFCTRL1); @@ -139,6 +142,8 @@ static void kvm_lose_pmu(struct kvm_vcpu *vcpu) val |= kvm_read_sw_gcsr(csr, LOONGARCH_CSR_PERFCTRL3); if (!(val & KVM_PMU_EVENT_ENABLED)) vcpu->arch.aux_inuse &= ~KVM_LARCH_PMU; + else + kvm_make_request(KVM_REQ_PMU, vcpu); kvm_restore_host_pmu(vcpu); } -- 2.39.3

1 month

1
0
0 0

[PATCH v2] drm/ast: Blank with VGACR17 sync enable, always clear VGACRB6 sync off

by Thomas Zimmermann

Blank the display by disabling sync pulses with VGACR17<7>. Unblank by reenabling them. This VGA setting should be supported by all Aspeed hardware. Ast currently blanks via sync-off bits in VGACRB6. Not all BMCs handle VGACRB6 correctly. After disabling sync during a reboot, some BMCs do not reenable it after the soft reset. The display output remains dark. When the display is off during boot, some BMCs set the sync-off bits in VGACRB6, so the display remains dark. Observed with Blackbird AST2500 BMCs. Clearing the sync-off bits unconditionally fixes these issues. Also do not modify VGASR1's SD bit for blanking, as it only disables GPU access to video memory. v2: - init vgacrb6 correctly (Jocelyn) Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Fixes: ce3d99c83495 ("drm: Call drm_atomic_helper_shutdown() at shutdown time for misc drivers") Tested-by: Nick Bowler <nbowler(a)draconx.ca> Reported-by: Nick Bowler <nbowler(a)draconx.ca> Closes: https://lore.kernel.org/dri-devel/wpwd7rit6t4mnu6kdqbtsnk5bhftgslio6e2jgkz6… Cc: Douglas Anderson <dianders(a)chromium.org> Cc: Dave Airlie <airlied(a)redhat.com> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Jocelyn Falempe <jfalempe(a)redhat.com> Cc: dri-devel(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v6.7+ --- drivers/gpu/drm/ast/ast_mode.c | 18 ++++++++++-------- drivers/gpu/drm/ast/ast_reg.h | 1 + 2 files changed, 11 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index 6b9d510c509d..9b6a7c54fbb5 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -836,22 +836,24 @@ ast_crtc_helper_atomic_flush(struct drm_crtc *crtc, static void ast_crtc_helper_atomic_enable(struct drm_crtc *crtc, struct drm_atomic_state *state) { struct ast_device *ast = to_ast_device(crtc->dev); + u8 vgacr17 = 0x00; + u8 vgacrb6 = 0xff; - ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0xb6, 0xfc, 0x00); - ast_set_index_reg_mask(ast, AST_IO_VGASRI, 0x01, 0xdf, 0x00); + vgacr17 |= AST_IO_VGACR17_SYNC_ENABLE; + vgacrb6 &= ~(AST_IO_VGACRB6_VSYNC_OFF | AST_IO_VGACRB6_HSYNC_OFF); + + ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0x17, 0x7f, vgacr17); + ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0xb6, 0xfc, vgacrb6); } static void ast_crtc_helper_atomic_disable(struct drm_crtc *crtc, struct drm_atomic_state *state) { struct drm_crtc_state *old_crtc_state = drm_atomic_get_old_crtc_state(state, crtc); struct ast_device *ast = to_ast_device(crtc->dev); - u8 vgacrb6; + u8 vgacr17 = 0xff; - ast_set_index_reg_mask(ast, AST_IO_VGASRI, 0x01, 0xdf, AST_IO_VGASR1_SD); - - vgacrb6 = AST_IO_VGACRB6_VSYNC_OFF | - AST_IO_VGACRB6_HSYNC_OFF; - ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0xb6, 0xfc, vgacrb6); + vgacr17 &= ~AST_IO_VGACR17_SYNC_ENABLE; + ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0x17, 0x7f, vgacr17); /* * HW cursors require the underlying primary plane and CRTC to diff --git a/drivers/gpu/drm/ast/ast_reg.h b/drivers/gpu/drm/ast/ast_reg.h index e15adaf3a80e..30578e3b07e4 100644 --- a/drivers/gpu/drm/ast/ast_reg.h +++ b/drivers/gpu/drm/ast/ast_reg.h @@ -29,6 +29,7 @@ #define AST_IO_VGAGRI (0x4E) #define AST_IO_VGACRI (0x54) +#define AST_IO_VGACR17_SYNC_ENABLE BIT(7) /* called "Hardware reset" in docs */ #define AST_IO_VGACR80_PASSWORD (0xa8) #define AST_IO_VGACR99_VGAMEM_RSRV_MASK GENMASK(1, 0) #define AST_IO_VGACRA1_VGAIO_DISABLED BIT(1) -- 2.51.0

1 month

3
13
0 0

[PATCH 0/4] mm, swap: misc cleanup and bugfix

by Kairui Song

A few cleanups and a bugfix that are either suitable after the swap table phase I or found during code review. Patch 1 is a bugfix and needs to be included in the stable branch, the rest have no behavior change. --- Kairui Song (4): mm, swap: do not perform synchronous discard during allocation mm, swap: rename helper for setup bad slots mm, swap: cleanup swap entry allocation parameter mm/migrate, swap: drop usage of folio_index include/linux/swap.h | 4 ++-- mm/migrate.c | 4 ++-- mm/shmem.c | 2 +- mm/swap.h | 21 ----------------- mm/swapfile.c | 64 ++++++++++++++++++++++++++++++++++++---------------- mm/vmscan.c | 4 ++-- 6 files changed, 52 insertions(+), 47 deletions(-) --- base-commit: 53e573001f2b5168f9b65d2b79e9563a3b479c17 change-id: 20251007-swap-clean-after-swap-table-p1-b9a7635ee3fa Best regards, -- Kairui Song <kasong(a)tencent.com>

1 month

5
15
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror