August 2024 - Linux-stable-mirror

[PATCH 1/5] HID: wacom: Defer calculation of resolution until resolution_code is known

by Gerecke, Jason

From: Jason Gerecke <jason.gerecke(a)wacom.com> The Wacom driver maps the HID_DG_TWIST usage to ABS_Z (rather than ABS_RZ) for historic reasons. When the code to support twist was introduced in commit 50066a042da5 ("HID: wacom: generic: Add support for height, tilt, and twist usages"), we were careful to write it in such a way that it had HID calculate the resolution of the twist axis assuming ABS_RZ instead (so that we would get correct angular behavior). This was broken with the introduction of commit 08a46b4190d3 ("HID: wacom: Set a default resolution for older tablets"), which moved the resolution calculation to occur *before* the adjustment from ABS_Z to ABS_RZ occurred. This commit moves the calculation of resolution after the point that we are finished setting things up for its proper use. Signed-off-by: Jason Gerecke <jason.gerecke(a)wacom.com> Fixes: 08a46b4190d3 ("HID: wacom: Set a default resolution for older tablets") Cc: stable(a)vger.kernel.org --- drivers/hid/wacom_wac.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c index 1f4564982b958..2541fa2e0fa3b 100644 --- a/drivers/hid/wacom_wac.c +++ b/drivers/hid/wacom_wac.c @@ -1878,12 +1878,14 @@ static void wacom_map_usage(struct input_dev *input, struct hid_usage *usage, int fmax = field->logical_maximum; unsigned int equivalent_usage = wacom_equivalent_usage(usage->hid); int resolution_code = code; - int resolution = hidinput_calc_abs_res(field, resolution_code); + int resolution; if (equivalent_usage == HID_DG_TWIST) { resolution_code = ABS_RZ; } + resolution = hidinput_calc_abs_res(field, resolution_code); + if (equivalent_usage == HID_GD_X) { fmin += features->offset_left; fmax -= features->offset_right; -- 2.45.2

11 months, 1 week

3
3
0 0

[PATCH v4] mm/hugetlb: fix hugetlb vs. core-mm PT locking

by David Hildenbrand

We recently made GUP's common page table walking code to also walk hugetlb VMAs without most hugetlb special-casing, preparing for the future of having less hugetlb-specific page table walking code in the codebase. Turns out that we missed one page table locking detail: page table locking for hugetlb folios that are not mapped using a single PMD/PUD. Assume we have hugetlb folio that spans multiple PTEs (e.g., 64 KiB hugetlb folios on arm64 with 4 KiB base page size). GUP, as it walks the page tables, will perform a pte_offset_map_lock() to grab the PTE table lock. However, hugetlb that concurrently modifies these page tables would actually grab the mm->page_table_lock: with USE_SPLIT_PTE_PTLOCKS, the locks would differ. Something similar can happen right now with hugetlb folios that span multiple PMDs when USE_SPLIT_PMD_PTLOCKS. This issue can be reproduced [1], for example triggering: [ 3105.936100] ------------[ cut here ]------------ [ 3105.939323] WARNING: CPU: 31 PID: 2732 at mm/gup.c:142 try_grab_folio+0x11c/0x188 [ 3105.944634] Modules linked in: [...] [ 3105.974841] CPU: 31 PID: 2732 Comm: reproducer Not tainted 6.10.0-64.eln141.aarch64 #1 [ 3105.980406] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-4.fc40 05/24/2024 [ 3105.986185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 3105.991108] pc : try_grab_folio+0x11c/0x188 [ 3105.994013] lr : follow_page_pte+0xd8/0x430 [ 3105.996986] sp : ffff80008eafb8f0 [ 3105.999346] x29: ffff80008eafb900 x28: ffffffe8d481f380 x27: 00f80001207cff43 [ 3106.004414] x26: 0000000000000001 x25: 0000000000000000 x24: ffff80008eafba48 [ 3106.009520] x23: 0000ffff9372f000 x22: ffff7a54459e2000 x21: ffff7a546c1aa978 [ 3106.014529] x20: ffffffe8d481f3c0 x19: 0000000000610041 x18: 0000000000000001 [ 3106.019506] x17: 0000000000000001 x16: ffffffffffffffff x15: 0000000000000000 [ 3106.024494] x14: ffffb85477fdfe08 x13: 0000ffff9372ffff x12: 0000000000000000 [ 3106.029469] x11: 1fffef4a88a96be1 x10: ffff7a54454b5f0c x9 : ffffb854771b12f0 [ 3106.034324] x8 : 0008000000000000 x7 : ffff7a546c1aa980 x6 : 0008000000000080 [ 3106.038902] x5 : 00000000001207cf x4 : 0000ffff9372f000 x3 : ffffffe8d481f000 [ 3106.043420] x2 : 0000000000610041 x1 : 0000000000000001 x0 : 0000000000000000 [ 3106.047957] Call trace: [ 3106.049522] try_grab_folio+0x11c/0x188 [ 3106.051996] follow_pmd_mask.constprop.0.isra.0+0x150/0x2e0 [ 3106.055527] follow_page_mask+0x1a0/0x2b8 [ 3106.058118] __get_user_pages+0xf0/0x348 [ 3106.060647] faultin_page_range+0xb0/0x360 [ 3106.063651] do_madvise+0x340/0x598 Let's make huge_pte_lockptr() effectively use the same PT locks as any core-mm page table walker would. Add ptep_lockptr() to obtain the PTE page table lock using a pte pointer -- unfortunately we cannot convert pte_lockptr() because virt_to_page() doesn't work with kmap'ed page tables we can have with CONFIG_HIGHPTE. Handle CONFIG_PGTABLE_LEVELS correctly by checking in reverse order, such that when e.g., CONFIG_PGTABLE_LEVELS==2 with PGDIR_SIZE==P4D_SIZE==PUD_SIZE==PMD_SIZE will work as expected. Document why that works. There is one ugly case: powerpc 8xx, whereby we have an 8 MiB hugetlb folio being mapped using two PTE page tables. While hugetlb wants to take the PMD table lock, core-mm would grab the PTE table lock of one of both PTE page tables. In such corner cases, we have to make sure that both locks match, which is (fortunately!) currently guaranteed for 8xx as it does not support SMP and consequently doesn't use split PT locks. [1] https://lore.kernel.org/all/1bbfcc7f-f222-45a5-ac44-c5a1381c596d@redhat.com/ Fixes: 9cb28da54643 ("mm/gup: handle hugetlb in the generic follow_page_mask code") Acked-by: Peter Xu <peterx(a)redhat.com> Cc: <stable(a)vger.kernel.org> Cc: Peter Xu <peterx(a)redhat.com> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Baolin Wang <baolin.wang(a)linux.alibaba.com> Signed-off-by: David Hildenbrand <david(a)redhat.com> --- @James, I dropped your RB. Retested on arm64 and x86-64. Cross-compiled on a bunch of others. v3 -> v4: * Replace PTE pointer alignment by BUILD_BUG_ON() * Simplify lock lookup by looking up in reverse * Adjust comment and patch description v2 -> v3: * Handle CONFIG_PGTABLE_LEVELS oddities as good as possible. It's a mess. Remove the size >= P4D_SIZE check and simply default to the &mm->page_table_lock. * Align the PTE pointer to the start of the page table to handle PTE page tables bigger than a single page (unclear if this could currently trigger). * Extend patch description v1 -> 2: * Extend patch description * Drop "mm: let pte_lockptr() consume a pte_t pointer" * Introduce ptep_lockptr() in this patch --- include/linux/hugetlb.h | 33 ++++++++++++++++++++++++++++++--- include/linux/mm.h | 11 +++++++++++ 2 files changed, 41 insertions(+), 3 deletions(-) diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index 8e462205400d..ac3ea8596f93 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -938,10 +938,37 @@ static inline bool htlb_allow_alloc_fallback(int reason) static inline spinlock_t *huge_pte_lockptr(struct hstate *h, struct mm_struct *mm, pte_t *pte) { - if (huge_page_size(h) == PMD_SIZE) + const unsigned long size = huge_page_size(h); + + VM_WARN_ON(size == PAGE_SIZE); + + /* + * hugetlb must use the exact same PT locks as core-mm page table + * walkers would. When modifying a PTE table, hugetlb must take the + * PTE PT lock, when modifying a PMD table, hugetlb must take the PMD + * PT lock etc. + * + * The expectation is that any hugetlb folio smaller than a PMD is + * always mapped into a single PTE table and that any hugetlb folio + * smaller than a PUD (but at least as big as a PMD) is always mapped + * into a single PMD table. + * + * If that does not hold for an architecture, then that architecture + * must disable split PT locks such that all *_lockptr() functions + * will give us the same result: the per-MM PT lock. + * + * Note that with e.g., CONFIG_PGTABLE_LEVELS=2 where + * PGDIR_SIZE==P4D_SIZE==PUD_SIZE==PMD_SIZE, we'd use pud_lockptr() + * and core-mm would use pmd_lockptr(). However, in such configurations + * split PMD locks are disabled -- they don't make sense on a single + * PGDIR page table -- and the end result is the same. + */ + if (size >= PUD_SIZE) + return pud_lockptr(mm, (pud_t *) pte); + else if (size >= PMD_SIZE || IS_ENABLED(CONFIG_HIGHPTE)) return pmd_lockptr(mm, (pmd_t *) pte); - VM_BUG_ON(huge_page_size(h) == PAGE_SIZE); - return &mm->page_table_lock; + /* pte_alloc_huge() only applies with !CONFIG_HIGHPTE */ + return ptep_lockptr(mm, pte); } #ifndef hugepages_supported diff --git a/include/linux/mm.h b/include/linux/mm.h index a890a1731c14..bd219ac9c026 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -2869,6 +2869,13 @@ static inline spinlock_t *pte_lockptr(struct mm_struct *mm, pmd_t *pmd) return ptlock_ptr(page_ptdesc(pmd_page(*pmd))); } +static inline spinlock_t *ptep_lockptr(struct mm_struct *mm, pte_t *pte) +{ + BUILD_BUG_ON(IS_ENABLED(CONFIG_HIGHPTE)); + BUILD_BUG_ON(MAX_PTRS_PER_PTE * sizeof(pte_t) > PAGE_SIZE); + return ptlock_ptr(virt_to_ptdesc(pte)); +} + static inline bool ptlock_init(struct ptdesc *ptdesc) { /* @@ -2893,6 +2900,10 @@ static inline spinlock_t *pte_lockptr(struct mm_struct *mm, pmd_t *pmd) { return &mm->page_table_lock; } +static inline spinlock_t *ptep_lockptr(struct mm_struct *mm, pte_t *pte) +{ + return &mm->page_table_lock; +} static inline void ptlock_cache_init(void) {} static inline bool ptlock_init(struct ptdesc *ptdesc) { return true; } static inline void ptlock_free(struct ptdesc *ptdesc) {} -- 2.45.2

11 months, 1 week

2
3
0 0

FAILED: patch "[PATCH] ipv4: fix source address selection with route leak" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 6807352353561187a718e87204458999dbcbba1b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024072916-pastrami-suction-5192@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 680735235356 ("ipv4: fix source address selection with route leak") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 6807352353561187a718e87204458999dbcbba1b Mon Sep 17 00:00:00 2001 From: Nicolas Dichtel <nicolas.dichtel(a)6wind.com> Date: Wed, 10 Jul 2024 10:14:27 +0200 Subject: [PATCH] ipv4: fix source address selection with route leak By default, an address assigned to the output interface is selected when the source address is not specified. This is problematic when a route, configured in a vrf, uses an interface from another vrf (aka route leak). The original vrf does not own the selected source address. Let's add a check against the output interface and call the appropriate function to select the source address. CC: stable(a)vger.kernel.org Fixes: 8cbb512c923d ("net: Add source address lookup op for VRF") Signed-off-by: Nicolas Dichtel <nicolas.dichtel(a)6wind.com> Reviewed-by: David Ahern <dsahern(a)kernel.org> Link: https://patch.msgid.link/20240710081521.3809742-2-nicolas.dichtel@6wind.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c index f669da98d11d..8956026bc0a2 100644 --- a/net/ipv4/fib_semantics.c +++ b/net/ipv4/fib_semantics.c @@ -2270,6 +2270,15 @@ void fib_select_path(struct net *net, struct fib_result *res, fib_select_default(fl4, res); check_saddr: - if (!fl4->saddr) - fl4->saddr = fib_result_prefsrc(net, res); + if (!fl4->saddr) { + struct net_device *l3mdev; + + l3mdev = dev_get_by_index_rcu(net, fl4->flowi4_l3mdev); + + if (!l3mdev || + l3mdev_master_dev_rcu(FIB_RES_DEV(*res)) == l3mdev) + fl4->saddr = fib_result_prefsrc(net, res); + else + fl4->saddr = inet_select_addr(l3mdev, 0, RT_SCOPE_LINK); + } }

11 months, 2 weeks

2
1
0 0

[PATCH 1/3] drm/amdgpu: Forward soft recovery errors to userspace

by Joshua Ashton

As we discussed before[1], soft recovery should be forwarded to userspace, or we can get into a really bad state where apps will keep submitting hanging command buffers cascading us to a hard reset. 1: https://lore.kernel.org/all/bf23d5ed-9a6b-43e7-84ee-8cbfd0d60f18@froggi.es/ Signed-off-by: Joshua Ashton <joshua(a)froggi.es> Cc: Friedrich Vock <friedrich.vock(a)gmx.de> Cc: Bas Nieuwenhuizen <bas(a)basnieuwenhuizen.nl> Cc: Christian König <christian.koenig(a)amd.com> Cc: André Almeida <andrealmeid(a)igalia.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c index 4b3000c21ef2..aebf59855e9f 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c @@ -262,9 +262,8 @@ amdgpu_job_prepare_job(struct drm_sched_job *sched_job, struct dma_fence *fence = NULL; int r; - /* Ignore soft recovered fences here */ r = drm_sched_entity_error(s_entity); - if (r && r != -ENODATA) + if (r) goto error; if (!fence && job->gang_submit) -- 2.44.0

11 months, 2 weeks

5
10
0 0

[PATCH net v1] net: wan: fsl_qmc_hdlc: Discard received CRC

by Herve Codina

Received frame from QMC contains the CRC. Upper layers don't need this CRC and tcpdump mentioned trailing junk data due to this CRC presence. As some other HDLC driver, simply discard this CRC. Fixes: d0f2258e79fd ("net: wan: Add support for QMC HDLC") Cc: stable(a)vger.kernel.org Signed-off-by: Herve Codina <herve.codina(a)bootlin.com> --- drivers/net/wan/fsl_qmc_hdlc.c | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/drivers/net/wan/fsl_qmc_hdlc.c b/drivers/net/wan/fsl_qmc_hdlc.c index 64b4bfa6fea7..8fcfbde31a1c 100644 --- a/drivers/net/wan/fsl_qmc_hdlc.c +++ b/drivers/net/wan/fsl_qmc_hdlc.c @@ -250,6 +250,7 @@ static void qmc_hcld_recv_complete(void *context, size_t length, unsigned int fl struct qmc_hdlc_desc *desc = context; struct net_device *netdev; struct qmc_hdlc *qmc_hdlc; + size_t crc_size; int ret; netdev = desc->netdev; @@ -268,15 +269,26 @@ static void qmc_hcld_recv_complete(void *context, size_t length, unsigned int fl if (flags & QMC_RX_FLAG_HDLC_CRC) /* CRC error */ netdev->stats.rx_crc_errors++; kfree_skb(desc->skb); - } else { - netdev->stats.rx_packets++; - netdev->stats.rx_bytes += length; + goto re_queue; + } - skb_put(desc->skb, length); - desc->skb->protocol = hdlc_type_trans(desc->skb, netdev); - netif_rx(desc->skb); + /* Discard the CRC */ + crc_size = qmc_hdlc->is_crc32 ? 4 : 2; + if (length < crc_size) { + netdev->stats.rx_length_errors++; + kfree_skb(desc->skb); + goto re_queue; } + length -= crc_size; + + netdev->stats.rx_packets++; + netdev->stats.rx_bytes += length; + + skb_put(desc->skb, length); + desc->skb->protocol = hdlc_type_trans(desc->skb, netdev); + netif_rx(desc->skb); +re_queue: /* Re-queue a transfer using the same descriptor */ ret = qmc_hdlc_recv_queue(qmc_hdlc, desc, desc->dma_size); if (ret) { -- 2.45.0

11 months, 2 weeks

4
3
0 0

[PATCH v4 RESEND] drm/client: fix null pointer dereference in drm_client_modeset_probe

by Ma Ke

In drm_client_modeset_probe(), the return value of drm_mode_duplicate() is assigned to modeset->mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. Cc: stable(a)vger.kernel.org Fixes: cf13909aee05 ("drm/fb-helper: Move out modeset config code") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v4: - modified patch, set ret and break to handle error rightly. Changes in v3: - modified patch as suggestions, returned error directly when failing to get modeset->mode. Changes in v2: - added the recipient's email address, due to the prolonged absence of a response from the recipients. - added Cc stable. --- drivers/gpu/drm/drm_client_modeset.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/drm_client_modeset.c b/drivers/gpu/drm/drm_client_modeset.c index 31af5cf37a09..cee5eafbfb81 100644 --- a/drivers/gpu/drm/drm_client_modeset.c +++ b/drivers/gpu/drm/drm_client_modeset.c @@ -880,6 +880,11 @@ int drm_client_modeset_probe(struct drm_client_dev *client, unsigned int width, kfree(modeset->mode); modeset->mode = drm_mode_duplicate(dev, mode); + if (!modeset->mode) { + ret = -ENOMEM; + break; + } + drm_connector_get(connector); modeset->connectors[modeset->num_connectors++] = connector; modeset->x = offset->x; -- 2.25.1

11 months, 2 weeks

2
2
0 0

[PATCH v3 RESEND] EDAC/ti: Fix possible null pointer dereference in _emif_get_id()

by Ma Ke

In _emif_get_id(), of_get_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 86a18ee21e5e ("EDAC, ti: Add support for TI keystone and DRA7xx EDAC") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v3: - added the patch operations omitted in PATCH v2 RESEND compared to PATCH v2. Sorry for my oversight. Changes in v2: - added Cc stable line. --- drivers/edac/ti_edac.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/edac/ti_edac.c b/drivers/edac/ti_edac.c index 29723c9592f7..6f3da8d99eab 100644 --- a/drivers/edac/ti_edac.c +++ b/drivers/edac/ti_edac.c @@ -207,6 +207,9 @@ static int _emif_get_id(struct device_node *node) int my_id = 0; addrp = of_get_address(node, 0, NULL, NULL); + if (!addrp) + return -EINVAL; + my_addr = (u32)of_translate_address(node, addrp); for_each_matching_node(np, ti_edac_of_match) { @@ -214,6 +217,9 @@ static int _emif_get_id(struct device_node *node) continue; addrp = of_get_address(np, 0, NULL, NULL); + if (!addrp) + return -EINVAL; + addr = (u32)of_translate_address(np, addrp); edac_printk(KERN_INFO, EDAC_MOD_NAME, -- 2.25.1

11 months, 2 weeks

2
1
0 0

[PATCH RESEND] EDAC/altera: Fix possible null pointer dereference

by Ma Ke

In altr_s10_sdram_check_ecc_deps(), of_get_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check. Cc: stable(a)vger.kernel.org Fixes: e1bca853dddc ("EDAC/altera: Add SDRAM ECC check for U-Boot") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/edac/altera_edac.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c index fe89f5c4837f..d6bf0eebeb41 100644 --- a/drivers/edac/altera_edac.c +++ b/drivers/edac/altera_edac.c @@ -1086,6 +1086,7 @@ static int altr_s10_sdram_check_ecc_deps(struct altr_edac_device_dev *device) struct arm_smccc_res result; struct device_node *np; phys_addr_t sdram_addr; + const __be32 *sdram_addrp; u32 read_reg; int ret; @@ -1093,8 +1094,14 @@ static int altr_s10_sdram_check_ecc_deps(struct altr_edac_device_dev *device) if (!np) goto sdram_err; - sdram_addr = of_translate_address(np, of_get_address(np, 0, - NULL, NULL)); + sdram_addrp = of_get_address(np, 0, NULL, NULL); + if (!sdram_addrp) + return -EINVAL; + + sdram_addr = of_translate_address(np, sdram_addrp); + if (!sdram_addr) + return -EINVAL; + of_node_put(np); sdram_ecc_addr = (unsigned long)sdram_addr + prv->ecc_en_ofst; arm_smccc_smc(INTEL_SIP_SMC_REG_READ, sdram_ecc_addr, -- 2.25.1

11 months, 2 weeks

2
1
0 0

[PATCH RESEND] drm/nouveau: fix a possible null pointer dereference

by Ma Ke

In ch7006_encoder_get_modes(), the return value of drm_mode_duplicate() is used directly in drm_mode_probed_add(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. Cc: stable(a)vger.kernel.org Fixes: 6ee738610f41 ("drm/nouveau: Add DRM driver for NVIDIA GPUs") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/gpu/drm/i2c/ch7006_drv.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c index 131512a5f3bd..48bf6e4e8bdb 100644 --- a/drivers/gpu/drm/i2c/ch7006_drv.c +++ b/drivers/gpu/drm/i2c/ch7006_drv.c @@ -229,6 +229,7 @@ static int ch7006_encoder_get_modes(struct drm_encoder *encoder, { struct ch7006_priv *priv = to_ch7006_priv(encoder); const struct ch7006_mode *mode; + struct drm_display_mode *encoder_mode = NULL; int n = 0; for (mode = ch7006_modes; mode->mode.clock; mode++) { @@ -236,8 +237,11 @@ static int ch7006_encoder_get_modes(struct drm_encoder *encoder, ~mode->valid_norms & 1<<priv->norm) continue; - drm_mode_probed_add(connector, - drm_mode_duplicate(encoder->dev, &mode->mode)); + encoder_mode = drm_mode_duplicate(encoder->dev, &mode->mode); + if (!encoder_mode) + return 0; + + drm_mode_probed_add(connector, encoder_mode); n++; } -- 2.25.1

11 months, 2 weeks

1
0
0 0

Kazakhstan Crude Oil Product Offer REF:fqgzib01

by Antonov|DPR

Dear stable, I hope this message finds you well. My name is Antonov, and I am a sales representative authorized by leading refineries in Kazakhstan to negotiate the sale of crude oil products worldwide. If you are interested in purchasing crude oil products, we can facilitate the process. The refinery has sufficient product allocation to supply to serious buyers. We currently offer a range of products including Petcoke, Ultra- Low Sulphur Diesel, East Siberia-Pacific Ocean (ESPO) Blend, Russian Light Cycle Oil (LCO), LNG, LPG, Jet Fuel, and more. All our products meet SGS and GOST-R standards, and we guarantee timely delivery. Thank you for your attention. I look forward to your response and to discussing further details. Best regards, Antonov Message REF1: ieztudr02Q Message Timestamp: 8/2/2024 4:19:59 a.m.

11 months, 2 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2024