Skip to content

[rlc-10/6.12.0-211.43.1.el10_2] Multiple patches tested (9 commits) - #1523

Open
ciq-kernel-automation[bot] wants to merge 9 commits into
rlc-10/6.12.0-211.43.1.el10_2from
{shreeya_gce}_rlc-10/6.12.0-211.43.1.el10_2
Open

[rlc-10/6.12.0-211.43.1.el10_2] Multiple patches tested (9 commits)#1523
ciq-kernel-automation[bot] wants to merge 9 commits into
rlc-10/6.12.0-211.43.1.el10_2from
{shreeya_gce}_rlc-10/6.12.0-211.43.1.el10_2

Conversation

@ciq-kernel-automation

@ciq-kernel-automation ciq-kernel-automation Bot commented Aug 10, 2026 •
edited
Loading

Copy link
Copy Markdown

Summary

This PR has been automatically created after successful completion of all CI stages.

Commit Message(s)

gve: move DQO rx buffer management related code to a new file

jira KERNEL-1217
commit-author Harshitha Ramamurthy <hramamurthy@google.com>
commit 93c68f1275f9e21ccfed9ee292aedb11c3f6241b

gve: clean XDP queues in gve_tx_stop_ring_gqi

jira KERNEL-1217
commit-author Joshua Washington <joshwash@google.com>
commit 6321f5fb70d502d95de8a212a7b484c297ec9644

gve: fix XDP allocation path in edge cases

jira KERNEL-1217
commit-author Joshua Washington <joshwash@google.com>
commit de63ac44a527b2c5067551dbd70d939fe151325a

gve: prevent ethtool ops after shutdown

jira KERNEL-1217
cve CVE-2025-38735
commit-author Jordan Rhee <jordanrhee@google.com>
commit 75a9a46d67f46d608205888f9b34e315c1786345

gve: defer interrupt enabling until NAPI registration

jira KERNEL-1217
commit-author Ankit Garg <nktgrg@google.com>
commit 3d970eda003441f66551a91fda16478ac0711617
upstream-diff RLC 10 does not carry the netif_napi_set_irq_locked()
  call this commit's gve_add_napi() hunk lands beside (it has
  block->irq but not the napi-irq wiring), so enable_irq(block->irq)
  is added directly after netif_napi_add_locked().

gve: fix incorrect buffer cleanup in gve_tx_clean_pending_packets for QPL

jira KERNEL-1217
commit-author Ankit Garg <nktgrg@google.com>
commit fb868db5f4bccd7a78219313ab2917429f715cea
upstream-diff The moved gve_unmap_packet() keeps this tree's
  dma_unmap_page() for the frag entries; the netmem conversion
  (netmem_dma_unmap_page_attrs) is not in this tree.

gve: Update QPL page registration logic

jira KERNEL-1217
commit-author Matt Olson <maolson@google.com>
commit 07993df560917357610e0625a9a2e7531c3211fc
upstream-diff Conflicts from the gve_queue_config split and page_pool/
  netmem/XDP refactors not in RLC 10. Kept RLC 10 struct names (qcfg/
  qcfg_tx, no num_xdp_rings) and datapath (no page_pool/xsk); the
  gve_update_num_qpl_pages() body is applied verbatim except
  rx_alloc_cfg->qcfg_rx->num_queues -> ->qcfg->num_queues. buffer-mgmt
  and rx_dqo num_buf_states use cfg->pages_per_qpl / priv->rx_pages_per_qpl.

gve: Enable reading max ring size from the device in DQO-QPL mode

jira KERNEL-1217
commit-author Matt Olson <maolson@google.com>
commit a2f19184014f309165d2d4cfb41088b75c1121a4

gve: bound DQO-QPL TX buffer count to the s16 free-list range

jira KERNEL-1217

Test Results

✅ Build Stage

Architecture Build Time Total Time
x86_64 40m 58s 42m 11s
aarch64 23m 40s 24m 20s

✅ Boot Verification

✅ Kernel Selftests

Architecture Passed Failed Compared Against Status
x86_64 427 65 rlc-10/6.12.0-211.43.1.el10_2 ⚠️ No baseline available
aarch64 710 112 rlc-10/6.12.0-211.43.1.el10_2 ⚠️ No baseline available

✅ LTP Results

Architecture Passed Failed Compared Against Status
x86_64 1478 80 rlc-10/6.12.0-211.43.1.el10_2 ⚠️ No baseline available
aarch64 1451 81 rlc-10/6.12.0-211.43.1.el10_2 ⚠️ No baseline available

🤖 This PR was automatically generated by GitHub Actions
Run ID: 31612573369

@ciq-kernel-automation ciq-kernel-automation Bot added the created-by-kernelci Tag PRs that were automatically created when a user branch was pushed to the repo (kernelCI) label Aug 10, 2026
PlaidCat
PlaidCat reviewed Aug 10, 2026
View reviewed changes
Comment thread drivers/net/ethernet/google/gve/gve_main.c
cfg->start_idx = 0;
cfg->num_rings = gve_num_tx_queues(priv);
cfg->num_rings = priv->tx_cfg.num_queues + num_xdp_queues;
cfg->pages_per_qpl = priv->tx_pages_per_qpl;

@PlaidCat PlaidCat Aug 10, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This conflict for the Upstream Diff is because this commit is older than gve: Update QPL page registration logic that introduced this.

PlaidCat
PlaidCat previously approved these changes Aug 10, 2026
View reviewed changes

@PlaidCat PlaidCat left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@PlaidCat
PlaidCat requested a review from a team August 10, 2026 21:37
bmastbergen
bmastbergen previously approved these changes Aug 10, 2026
View reviewed changes

@bmastbergen bmastbergen left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🥌

@shreeya-patel98
gve: move DQO rx buffer management related code to a new file
6929457 
jira KERNEL-1217
commit-author Harshitha Ramamurthy <hramamurthy@google.com>
commit 93c68f1

In preparation for the upcoming page pool adoption for DQO
raw addressing mode, move RX buffer management code to a new
file. In the follow on patches, page pool code will be added
to this file.

No functional change, just movement of code.

	Reviewed-by: Praveen Kaligineedi <pkaligineedi@google.com>
	Reviewed-by: Shailend Chand <shailend@google.com>
	Reviewed-by: Willem de Bruijn <willemb@google.com>
	Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
	Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20241014202108.1051963-2-pkaligineedi@google.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 93c68f1)
	Signed-off-by: Shreeya Patel <spatel@ciq.com>
@shreeya-patel98
shreeya-patel98 dismissed stale reviews from bmastbergen and PlaidCat via 08c15b7 August 11, 2026 18:20
@shreeya-patel98
shreeya-patel98 force-pushed the {shreeya_gce}_rlc-10/6.12.0-211.43.1.el10_2 branch 4 times, most recently from 263a2e3 to 8f2af94 Compare August 11, 2026 19:11
@ciq-kernel-automation ciq-kernel-automation Bot changed the title [rlc-10/6.12.0-211.43.1.el10_2] Multiple patches tested (4 commits) [rlc-10/6.12.0-211.43.1.el10_2] Multiple patches tested (5 commits) Aug 11, 2026
@shreeya-patel98
shreeya-patel98 requested review from a team, PlaidCat and bmastbergen August 12, 2026 12:02
josh8551021 and others added 7 commits August 12, 2026 12:35
@josh8551021 @shreeya-patel98
gve: clean XDP queues in gve_tx_stop_ring_gqi
6ed2779 
jira KERNEL-1217
commit-author Joshua Washington <joshwash@google.com>
commit 6321f5f

When stopping XDP TX rings, the XDP clean function needs to be called to
clean out the entire queue, similar to what happens in the normal TX
queue case. Otherwise, the FIFO won't be cleared correctly, and
xsk_tx_completed won't be reported.

Fixes: 75eaae1 ("gve: Add XDP DROP and TX support for GQI-QPL format")
	Cc: stable@vger.kernel.org
	Signed-off-by: Joshua Washington <joshwash@google.com>
	Signed-off-by: Praveen Kaligineedi <pkaligineedi@google.com>
	Reviewed-by: Praveen Kaligineedi <pkaligineedi@google.com>
	Reviewed-by: Willem de Bruijn <willemb@google.com>
	Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 6321f5f)
	Signed-off-by: Shreeya Patel <spatel@ciq.com>
@josh8551021 @shreeya-patel98
gve: fix XDP allocation path in edge cases
d09e465 
jira KERNEL-1217
commit-author Joshua Washington <joshwash@google.com>
commit de63ac4

This patch fixes a number of consistency issues in the queue allocation
path related to XDP.

As it stands, the number of allocated XDP queues changes in three
different scenarios.
1) Adding an XDP program while the interface is up via
   gve_add_xdp_queues
2) Removing an XDP program while the interface is up via
   gve_remove_xdp_queues
3) After queues have been allocated and the old queue memory has been
   removed in gve_queues_start.

However, the requirement for the interface to be up for
gve_(add|remove)_xdp_queues to be called, in conjunction with the fact
that the number of queues stored in priv isn't updated until _after_ XDP
queues have been allocated in the normal queue allocation path means
that if an XDP program is added while the interface is down, XDP queues
won't be added until the _second_ if_up, not the first.

Given the expectation that the number of XDP queues is equal to the
number of RX queues, scenario (3) has another problematic implication.
When changing the number of queues while an XDP program is loaded, the
number of XDP queues must be updated as well, as there is logic in the
driver (gve_xdp_tx_queue_id()) which relies on every RX queue having a
corresponding XDP TX queue. However, the number of XDP queues stored in
priv would not be updated until _after_ a close/open leading to a
mismatch in the number of XDP queues reported vs the number of XDP
queues which actually exist after the queue count update completes.

This patch remedies these issues by doing the following:
1) The allocation config getter function is set up to retrieve the
   _expected_ number of XDP queues to allocate instead of relying
   on the value stored in `priv` which is only updated once the queues
   have been allocated.
2) When adjusting queues, XDP queues are adjusted to match the number of
   RX queues when XDP is enabled. This only works in the case when
   queues are live, so part (1) of the fix must still be available in
   the case that queues are adjusted when there is an XDP program and
   the interface is down.

Fixes: 5f08cd3 ("gve: Alloc before freeing when adjusting queues")
Cc: stable@vger.kernel.org
	Signed-off-by: Joshua Washington <joshwash@google.com>
	Signed-off-by: Praveen Kaligineedi <pkaligineedi@google.com>
	Reviewed-by: Praveen Kaligineedi <pkaligineedi@google.com>
	Reviewed-by: Shailend Chand <shailend@google.com>
	Reviewed-by: Willem de Bruijn <willemb@google.com>
	Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit de63ac4)
	Signed-off-by: Shreeya Patel <spatel@ciq.com>
@jordanrh1 @shreeya-patel98
gve: prevent ethtool ops after shutdown
6bf6df5 
jira KERNEL-1217
cve CVE-2025-38735
commit-author Jordan Rhee <jordanrhee@google.com>
commit 75a9a46

A crash can occur if an ethtool operation is invoked
after shutdown() is called.

shutdown() is invoked during system shutdown to stop DMA operations
without performing expensive deallocations. It is discouraged to
unregister the netdev in this path, so the device may still be visible
to userspace and kernel helpers.

In gve, shutdown() tears down most internal data structures. If an
ethtool operation is dispatched after shutdown(), it will dereference
freed or NULL pointers, leading to a kernel panic. While graceful
shutdown normally quiesces userspace before invoking the reboot
syscall, forced shutdowns (as observed on GCP VMs) can still trigger
this path.

Fix by calling netif_device_detach() in shutdown().
This marks the device as detached so the ethtool ioctl handler
will skip dispatching operations to the driver.

Fixes: 974365e ("gve: Implement suspend/resume/shutdown")
	Signed-off-by: Jordan Rhee <jordanrhee@google.com>
	Signed-off-by: Jeroen de Borst <jeroendb@google.com>
Link: https://patch.msgid.link/20250818211245.1156919-1-jeroendb@google.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 75a9a46)
	Signed-off-by: Shreeya Patel <spatel@ciq.com>
@agarg2008 @shreeya-patel98
gve: defer interrupt enabling until NAPI registration
ddac3ef 
jira KERNEL-1217
commit-author Ankit Garg <nktgrg@google.com>
commit 3d970ed
upstream-diff RLC 10 does not carry the netif_napi_set_irq_locked()
  call this commit's gve_add_napi() hunk lands beside (it has
  block->irq but not the napi-irq wiring), so enable_irq(block->irq)
  is added directly after netif_napi_add_locked().

Currently, interrupts are automatically enabled immediately upon
request. This allows interrupt to fire before the associated NAPI
context is fully initialized and cause failures like below:

[    0.946369] Call Trace:
[    0.946369]  <IRQ>
[    0.946369]  __napi_poll+0x2a/0x1e0
[    0.946369]  net_rx_action+0x2f9/0x3f0
[    0.946369]  handle_softirqs+0xd6/0x2c0
[    0.946369]  ? handle_edge_irq+0xc1/0x1b0
[    0.946369]  __irq_exit_rcu+0xc3/0xe0
[    0.946369]  common_interrupt+0x81/0xa0
[    0.946369]  </IRQ>
[    0.946369]  <TASK>
[    0.946369]  asm_common_interrupt+0x22/0x40
[    0.946369] RIP: 0010:pv_native_safe_halt+0xb/0x10

Use the `IRQF_NO_AUTOEN` flag when requesting interrupts to prevent auto
enablement and explicitly enable the interrupt in NAPI initialization
path (and disable it during NAPI teardown).

This ensures that interrupt lifecycle is strictly coupled with
readiness of NAPI context.

Cc: stable@vger.kernel.org
Fixes: 1dfc2e4 ("gve: Refactor napi add and remove functions")
	Signed-off-by: Ankit Garg <nktgrg@google.com>
	Reviewed-by: Jordan Rhee <jordanrhee@google.com>
	Reviewed-by: Joshua Washington <joshwash@google.com>
	Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
	Link: https://patch.msgid.link/20251219102945.2193617-1-hramamurthy@google.com
	Signed-off-by: Paolo Abeni <pabeni@redhat.com>

(cherry picked from commit 3d970ed)
	Signed-off-by: Shreeya Patel <spatel@ciq.com>
@agarg2008 @shreeya-patel98
gve: fix incorrect buffer cleanup in gve_tx_clean_pending_packets for…
934a808 
… QPL

jira KERNEL-1217
commit-author Ankit Garg <nktgrg@google.com>
commit fb868db
upstream-diff The moved gve_unmap_packet() keeps this tree's
  dma_unmap_page() for the frag entries; the netmem conversion
  (netmem_dma_unmap_page_attrs) is not in this tree.

In DQ-QPL mode, gve_tx_clean_pending_packets() incorrectly uses the RDA
buffer cleanup path. It iterates num_bufs times and attempts to unmap
entries in the dma array.

This leads to two issues:
1. The dma array shares storage with tx_qpl_buf_ids (union).
 Interpreting buffer IDs as DMA addresses results in attempting to
 unmap incorrect memory locations.
2. num_bufs in QPL mode (counting 2K chunks) can significantly exceed
 the size of the dma array, causing out-of-bounds access warnings
(trace below is how we noticed this issue).

UBSAN: array-index-out-of-bounds in
drivers/net/ethernet/drivers/net/ethernet/google/gve/gve_tx_dqo.c:178:5 index 18 is out of
range for type 'dma_addr_t[18]' (aka 'unsigned long long[18]')
Workqueue: gve gve_service_task [gve]
Call Trace:
<TASK>
dump_stack_lvl+0x33/0xa0
__ubsan_handle_out_of_bounds+0xdc/0x110
gve_tx_stop_ring_dqo+0x182/0x200 [gve]
gve_close+0x1be/0x450 [gve]
gve_reset+0x99/0x120 [gve]
gve_service_task+0x61/0x100 [gve]
process_scheduled_works+0x1e9/0x380

Fix this by properly checking for QPL mode and delegating to
gve_free_tx_qpl_bufs() to reclaim the buffers.

Cc: stable@vger.kernel.org
Fixes: a6fb8d5 ("gve: Tx path for DQO-QPL")
	Signed-off-by: Ankit Garg <nktgrg@google.com>
	Reviewed-by: Jordan Rhee <jordanrhee@google.com>
	Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
	Signed-off-by: Joshua Washington <joshwash@google.com>
	Reviewed-by: Simon Horman <horms@kernel.org>
	Link: https://patch.msgid.link/20260220215324.1631350-1-joshwash@google.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>

(cherry picked from commit fb868db)
	Signed-off-by: Shreeya Patel <spatel@ciq.com>
@shreeya-patel98
gve: Update QPL page registration logic
f40d8d5 
jira KERNEL-1217
commit-author Matt Olson <maolson@google.com>
commit 07993df
upstream-diff Conflicts from the gve_queue_config split and page_pool/
  netmem/XDP refactors not in RLC 10. Kept RLC 10 struct names (qcfg/
  qcfg_tx, no num_xdp_rings) and datapath (no page_pool/xsk); the
  gve_update_num_qpl_pages() body is applied verbatim except
  rx_alloc_cfg->qcfg_rx->num_queues -> ->qcfg->num_queues. buffer-mgmt
  and rx_dqo num_buf_states use cfg->pages_per_qpl / priv->rx_pages_per_qpl.

For DQO, change QPL page registration logic to be more flexible to honor
the "max_registered_pages" parameter from the gVNIC device.

Previously the number of RX pages per QPL was hardcoded to twice the
ring size, and the number of TX pages per QPL was dictated by the device
in the DQO-QPL device option. Now [in DQO-QPL mode], the driver will
ignore the "tx_pages_per_qpl" parameter indicated in the DQO-QPL device
option and instead allocate up to (tx_queue_length / 2) pages per TX QPL
and up to (rx_queue_length * 2) pages per RX QPL while keeping the total
number of pages under the "max_registered_pages".

Merge DQO and GQI QPL page calculation logic into a unified
gve_update_num_qpl_pages function. Add rx_pages_per_qpl to the priv
struct for consumption by both DQO and GQI.

	Signed-off-by: Matt Olson <maolson@google.com>
	Signed-off-by: Max Yuan <maxyuan@google.com>
	Reviewed-by: Jordan Rhee <jordanrhee@google.com>
	Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
	Reviewed-by: Willem de Bruijn <willemb@google.com>
	Reviewed-by: Praveen Kaligineedi <pkaligineedi@google.com>
	Signed-off-by: Joshua Washington <joshwash@google.com>
	Link: https://patch.msgid.link/20260225182342.1049816-2-joshwash@google.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 07993df)
	Signed-off-by: Shreeya Patel <spatel@ciq.com>
@shreeya-patel98
gve: Enable reading max ring size from the device in DQO-QPL mode
0d7f93a 
jira KERNEL-1217
commit-author Matt Olson <maolson@google.com>
commit a2f1918

The gVNIC device indicates a device option (MODIFY_RING) to the driver,
which presents a range of ring sizes from which the user is allowed to
select. But in DQO-QPL queue format, the driver ignores the "max" of
this range and instead allows the user to configure the ring size in the
range [min, default]. This was done because increasing the ring size
could result in the number of registered pages being higher than the max
allowed by the device.

In order to support large ring sizes, stop ignoring the "max" of the
range presented in the MODIFY_RING option.

	Signed-off-by: Matt Olson <maolson@google.com>
	Signed-off-by: Max Yuan <maxyuan@google.com>
	Reviewed-by: Jordan Rhee <jordanrhee@google.com>
	Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
	Reviewed-by: Praveen Kaligineedi <pkaligineedi@google.com>
	Signed-off-by: Joshua Washington <joshwash@google.com>
Link: https://patch.msgid.link/20260225182342.1049816-3-joshwash@google.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit a2f1918)
	Signed-off-by: Shreeya Patel <spatel@ciq.com>
@bmastbergen
bmastbergen removed the request for review from a team August 12, 2026 14:09
@shreeya-patel98
shreeya-patel98 force-pushed the {shreeya_gce}_rlc-10/6.12.0-211.43.1.el10_2 branch from 8f2af94 to aad8983 Compare August 12, 2026 15:29
@shreeya-patel98
gve: bound DQO-QPL TX buffer count to the s16 free-list range
a9b91ee 
jira KERNEL-1217

gve_tx_qpl_buf_init() sizes the TX buffer free list as
GVE_TX_BUFS_PER_PAGE_DQO * num_entries, but the free-list links
(tx_qpl_buf_next) are s16.  GVE_TX_BUFS_PER_PAGE_DQO is PAGE_SIZE >> 11,
so on 64K-page builds (the aarch64-64k config ships CONFIG_GVE=m) a
4096-entry TX ring yields 2048 pages and 65536 buffers: entry 32767 is
seeded with a link of 32768, which reads back as -32768, and once 32768
buffers have been allocated gve_alloc_tx_qpl_buf() dereferences
tx_qpl_buf_next[-32768] and returns ids that index outside the QPL.

Clamp the count to S16_MAX, leaving an oversized QPL's tail unused
rather than mislinked.

This is not unique to this backport: upstream has the same unclamped
math at its tip. Kept as a separate commit so it can be dropped in
favor of the upstream fix once one lands;

Fixes: 07993df ("gve: Update QPL page registration logic")
Signed-off-by: Shreeya Patel <spatel@ciq.com>
@shreeya-patel98
shreeya-patel98 force-pushed the {shreeya_gce}_rlc-10/6.12.0-211.43.1.el10_2 branch from aad8983 to a9b91ee Compare August 12, 2026 15:44
bmastbergen
bmastbergen approved these changes Aug 12, 2026
View reviewed changes

@bmastbergen bmastbergen left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🥌

@ciq-kernel-automation ciq-kernel-automation Bot changed the title [rlc-10/6.12.0-211.43.1.el10_2] Multiple patches tested (5 commits) [rlc-10/6.12.0-211.43.1.el10_2] Multiple patches tested (9 commits) Aug 12, 2026
@shreeya-patel98
shreeya-patel98 requested a review from a team August 13, 2026 12:22
PlaidCat
PlaidCat approved these changes Aug 13, 2026
View reviewed changes

@PlaidCat PlaidCat left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

I'm good with these changes since this has been a long review I'd like @kerneltoast to also approve.

@PlaidCat
PlaidCat requested a review from a team August 13, 2026 12:40
bmastbergen
bmastbergen approved these changes Aug 13, 2026
View reviewed changes

@bmastbergen bmastbergen left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🥌

@PlaidCat
PlaidCat requested a review from a team August 13, 2026 17:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@PlaidCat PlaidCat PlaidCat approved these changes
@bmastbergen bmastbergen bmastbergen approved these changes

Assignees

No one assigned

Labels

created-by-kernelci Tag PRs that were automatically created when a user branch was pushed to the repo (kernelCI)

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

6 participants

@PlaidCat @bmastbergen @shreeya-patel98 @josh8551021 @jordanrh1 @agarg2008