1. 08 Nov, 2016 25 commits
  2. 28 Oct, 2016 15 commits
    • Paul E. McKenney's avatar
      compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release() · afe98b3b
      Paul E. McKenney authored
      commit 536fa402 upstream.
      
      CPUs without single-byte and double-byte loads and stores place some
      "interesting" requirements on concurrent code.  For example (adapted
      from Peter Hurley's test code), suppose we have the following structure:
      
      	struct foo {
      		spinlock_t lock1;
      		spinlock_t lock2;
      		char a; /* Protected by lock1. */
      		char b; /* Protected by lock2. */
      	};
      	struct foo *foop;
      
      Of course, it is common (and good) practice to place data protected
      by different locks in separate cache lines.  However, if the locks are
      rarely acquired (for example, only in rare error cases), and there are
      a great many instances of the data structure, then memory footprint can
      trump false-sharing concerns, so that it can be better to place them in
      the same cache cache line as above.
      
      But if the CPU does not support single-byte loads and stores, a store
      to foop->a will do a non-atomic read-modify-write operation on foop->b,
      which will come as a nasty surprise to someone holding foop->lock2.  So we
      now require CPUs to support single-byte and double-byte loads and stores.
      Therefore, this commit adjusts the definition of __native_word() to allow
      these sizes to be used by smp_load_acquire() and smp_store_release().
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      afe98b3b
    • Guenter Roeck's avatar
      metag: Only define atomic_dec_if_positive conditionally · e4dfd365
      Guenter Roeck authored
      commit 35d04077 upstream.
      
      The definition of atomic_dec_if_positive() assumes that
      atomic_sub_if_positive() exists, which is only the case if
      metag specific atomics are used. This results in the following
      build error when trying to build metag1_defconfig.
      
      kernel/ucount.c: In function 'dec_ucount':
      kernel/ucount.c:211: error:
      	implicit declaration of function 'atomic_sub_if_positive'
      
      Moving the definition of atomic_dec_if_positive() into the metag
      conditional code fixes the problem.
      
      Fixes: 6006c0d8 ("metag: Atomics, locks and bitops")
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      e4dfd365
    • Ming Lei's avatar
      scsi: Fix use-after-free · 04b46ca8
      Ming Lei authored
      commit bcd8f2e9 upstream.
      
      This patch fixes one use-after-free report[1] by KASAN.
      
      In __scsi_scan_target(), when a type 31 device is probed,
      SCSI_SCAN_TARGET_PRESENT is returned and the target will be scanned
      again.
      
      Inside the following scsi_report_lun_scan(), one new scsi_device
      instance is allocated, and scsi_probe_and_add_lun() is called again to
      probe the target and still see type 31 device, finally
      __scsi_remove_device() is called to remove & free the device at the end
      of scsi_probe_and_add_lun(), so cause use-after-free in
      scsi_report_lun_scan().
      
      And the following SCSI log can be observed:
      
      	scsi 0:0:2:0: scsi scan: INQUIRY pass 1 length 36
      	scsi 0:0:2:0: scsi scan: INQUIRY successful with code 0x0
      	scsi 0:0:2:0: scsi scan: peripheral device type of 31, no device added
      	scsi 0:0:2:0: scsi scan: Sending REPORT LUNS to (try 0)
      	scsi 0:0:2:0: scsi scan: REPORT LUNS successful (try 0) result 0x0
      	scsi 0:0:2:0: scsi scan: REPORT LUN scan
      	scsi 0:0:2:0: scsi scan: INQUIRY pass 1 length 36
      	scsi 0:0:2:0: scsi scan: INQUIRY successful with code 0x0
      	scsi 0:0:2:0: scsi scan: peripheral device type of 31, no device added
      	BUG: KASAN: use-after-free in __scsi_scan_target+0xbf8/0xe40 at addr ffff88007b44a104
      
      This patch fixes the issue by moving the putting reference at
      the end of scsi_report_lun_scan().
      
      [1] KASAN report
      ==================================================================
      [    3.274597] PM: Adding info for serio:serio1
      [    3.275127] BUG: KASAN: use-after-free in __scsi_scan_target+0xd87/0xdf0 at addr ffff880254d8c304
      [    3.275653] Read of size 4 by task kworker/u10:0/27
      [    3.275903] CPU: 3 PID: 27 Comm: kworker/u10:0 Not tainted 4.8.0 #2121
      [    3.276258] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
      [    3.276797] Workqueue: events_unbound async_run_entry_fn
      [    3.277083]  ffff880254d8c380 ffff880259a37870 ffffffff94bbc6c1 ffff880078402d80
      [    3.277532]  ffff880254d8bb80 ffff880259a37898 ffffffff9459fec1 ffff880259a37930
      [    3.277989]  ffff880254d8bb80 ffff880078402d80 ffff880259a37920 ffffffff945a0165
      [    3.278436] Call Trace:
      [    3.278528]  [<ffffffff94bbc6c1>] dump_stack+0x65/0x84
      [    3.278797]  [<ffffffff9459fec1>] kasan_object_err+0x21/0x70
      [    3.279063] device: 'psaux': device_add
      [    3.279616]  [<ffffffff945a0165>] kasan_report_error+0x205/0x500
      [    3.279651] PM: Adding info for No Bus:psaux
      [    3.280202]  [<ffffffff944ecd22>] ? kfree_const+0x22/0x30
      [    3.280486]  [<ffffffff94bc2dc9>] ? kobject_release+0x119/0x370
      [    3.280805]  [<ffffffff945a0543>] __asan_report_load4_noabort+0x43/0x50
      [    3.281170]  [<ffffffff9507e1f7>] ? __scsi_scan_target+0xd87/0xdf0
      [    3.281506]  [<ffffffff9507e1f7>] __scsi_scan_target+0xd87/0xdf0
      [    3.281848]  [<ffffffff9507d470>] ? scsi_add_device+0x30/0x30
      [    3.282156]  [<ffffffff94f7f660>] ? pm_runtime_autosuspend_expiration+0x60/0x60
      [    3.282570]  [<ffffffff956ddb07>] ? _raw_spin_lock+0x17/0x40
      [    3.282880]  [<ffffffff9507e505>] scsi_scan_channel+0x105/0x160
      [    3.283200]  [<ffffffff9507e8a2>] scsi_scan_host_selected+0x212/0x2f0
      [    3.283563]  [<ffffffff9507eb3c>] do_scsi_scan_host+0x1bc/0x250
      [    3.283882]  [<ffffffff9507efc1>] do_scan_async+0x41/0x450
      [    3.284173]  [<ffffffff941c1fee>] async_run_entry_fn+0xfe/0x610
      [    3.284492]  [<ffffffff941a8954>] ? pwq_dec_nr_in_flight+0x124/0x2a0
      [    3.284876]  [<ffffffff941d1770>] ? preempt_count_add+0x130/0x160
      [    3.285207]  [<ffffffff941a9a84>] process_one_work+0x544/0x12d0
      [    3.285526]  [<ffffffff941aa8e9>] worker_thread+0xd9/0x12f0
      [    3.285844]  [<ffffffff941aa810>] ? process_one_work+0x12d0/0x12d0
      [    3.286182]  [<ffffffff941bb365>] kthread+0x1c5/0x260
      [    3.286443]  [<ffffffff940855cd>] ? __switch_to+0x88d/0x1430
      [    3.286745]  [<ffffffff941bb1a0>] ? kthread_worker_fn+0x5a0/0x5a0
      [    3.287085]  [<ffffffff956dde9f>] ret_from_fork+0x1f/0x40
      [    3.287368]  [<ffffffff941bb1a0>] ? kthread_worker_fn+0x5a0/0x5a0
      [    3.287697] Object at ffff880254d8bb80, in cache kmalloc-2048 size: 2048
      [    3.288064] Allocated:
      [    3.288147] PID = 27
      [    3.288218]  [<ffffffff940b27ab>] save_stack_trace+0x2b/0x50
      [    3.288531]  [<ffffffff9459f246>] save_stack+0x46/0xd0
      [    3.288806]  [<ffffffff9459f4bd>] kasan_kmalloc+0xad/0xe0
      [    3.289098]  [<ffffffff9459c07e>] __kmalloc+0x13e/0x250
      [    3.289378]  [<ffffffff95078e5a>] scsi_alloc_sdev+0xea/0xcf0
      [    3.289701]  [<ffffffff9507de76>] __scsi_scan_target+0xa06/0xdf0
      [    3.290034]  [<ffffffff9507e505>] scsi_scan_channel+0x105/0x160
      [    3.290362]  [<ffffffff9507e8a2>] scsi_scan_host_selected+0x212/0x2f0
      [    3.290724]  [<ffffffff9507eb3c>] do_scsi_scan_host+0x1bc/0x250
      [    3.291055]  [<ffffffff9507efc1>] do_scan_async+0x41/0x450
      [    3.291354]  [<ffffffff941c1fee>] async_run_entry_fn+0xfe/0x610
      [    3.291695]  [<ffffffff941a9a84>] process_one_work+0x544/0x12d0
      [    3.292022]  [<ffffffff941aa8e9>] worker_thread+0xd9/0x12f0
      [    3.292325]  [<ffffffff941bb365>] kthread+0x1c5/0x260
      [    3.292594]  [<ffffffff956dde9f>] ret_from_fork+0x1f/0x40
      [    3.292886] Freed:
      [    3.292945] PID = 27
      [    3.293016]  [<ffffffff940b27ab>] save_stack_trace+0x2b/0x50
      [    3.293327]  [<ffffffff9459f246>] save_stack+0x46/0xd0
      [    3.293600]  [<ffffffff9459fa61>] kasan_slab_free+0x71/0xb0
      [    3.293916]  [<ffffffff9459bac2>] kfree+0xa2/0x1f0
      [    3.294168]  [<ffffffff9508158a>] scsi_device_dev_release_usercontext+0x50a/0x730
      [    3.294598]  [<ffffffff941ace9a>] execute_in_process_context+0xda/0x130
      [    3.294974]  [<ffffffff9508107c>] scsi_device_dev_release+0x1c/0x20
      [    3.295322]  [<ffffffff94f566f6>] device_release+0x76/0x1e0
      [    3.295626]  [<ffffffff94bc2db7>] kobject_release+0x107/0x370
      [    3.295942]  [<ffffffff94bc29ce>] kobject_put+0x4e/0xa0
      [    3.296222]  [<ffffffff94f56e17>] put_device+0x17/0x20
      [    3.296497]  [<ffffffff9505201c>] scsi_device_put+0x7c/0xa0
      [    3.296801]  [<ffffffff9507e1bc>] __scsi_scan_target+0xd4c/0xdf0
      [    3.297132]  [<ffffffff9507e505>] scsi_scan_channel+0x105/0x160
      [    3.297458]  [<ffffffff9507e8a2>] scsi_scan_host_selected+0x212/0x2f0
      [    3.297829]  [<ffffffff9507eb3c>] do_scsi_scan_host+0x1bc/0x250
      [    3.298156]  [<ffffffff9507efc1>] do_scan_async+0x41/0x450
      [    3.298453]  [<ffffffff941c1fee>] async_run_entry_fn+0xfe/0x610
      [    3.298777]  [<ffffffff941a9a84>] process_one_work+0x544/0x12d0
      [    3.299105]  [<ffffffff941aa8e9>] worker_thread+0xd9/0x12f0
      [    3.299408]  [<ffffffff941bb365>] kthread+0x1c5/0x260
      [    3.299676]  [<ffffffff956dde9f>] ret_from_fork+0x1f/0x40
      [    3.299967] Memory state around the buggy address:
      [    3.300209]  ffff880254d8c200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [    3.300608]  ffff880254d8c280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [    3.300986] >ffff880254d8c300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [    3.301408]                    ^
      [    3.301550]  ffff880254d8c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [    3.301987]  ffff880254d8c400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [    3.302396]
      ==================================================================
      
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMing Lei <tom.leiming@gmail.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      04b46ca8
    • Trond Myklebust's avatar
      NFSv4: Open state recovery must account for file permission changes · b160dbbd
      Trond Myklebust authored
      commit 304020fe upstream.
      
      If the file permissions change on the server, then we may not be able to
      recover open state. If so, we need to ensure that we mark the file
      descriptor appropriately.
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Tested-by: default avatarOleg Drokin <green@linuxhacker.ru>
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      b160dbbd
    • Dmitry Torokhov's avatar
      Input: elantech - add Fujitsu Lifebook E556 to force crc_enabled · 689c691b
      Dmitry Torokhov authored
      commit 62837b3c upstream.
      
      Another Lifebook machine that needs the same quirk as other similar
      models to make the driver working.
      
      Also let's reorder elantech_dmi_force_crc_enabled list so LIfebook enries
      are in alphabetical order.
      Reported-by: default avatarWilliam Linna <william.linna@gmail.com>
      Tested-by: default avatarWilliam Linna <william.linna@gmail.com>
      Reviewed-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      689c691b
    • Matti Kurkela's avatar
      Input: elantech - force needed quirks on Fujitsu H760 · 2ace5a25
      Matti Kurkela authored
      commit f9a703a5 upstream.
      
      Just like Fujitsu CELSIUS H730, the H760 also has an Elantech touchpad with
      the same quirks. Without this patch, the touchpad is useless out-of-the-box
      as the mouse pointer won't move.
      
      This patch makes the driver aware of both the crc_enabled=1 requirement and
      the middle button, making the touchpad fully functional out-of-the-box.
      Signed-off-by: default avatarMatti Kurkela <Matti.Kurkela@iki.fi>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      2ace5a25
    • Marcin Nowakowski's avatar
      MIPS: ptrace: Fix regs_return_value for kernel context · 75393dbe
      Marcin Nowakowski authored
      commit 74f1077b upstream.
      
      Currently regs_return_value always negates reg[2] if it determines
      the syscall has failed, but when called in kernel context this check is
      invalid and may result in returning a wrong value.
      
      This fixes errors reported by CONFIG_KPROBES_SANITY_TEST
      
      Fixes: d7e7528b ("Audit: push audit success and retcode into arch ptrace.h")
      Signed-off-by: default avatarMarcin Nowakowski <marcin.nowakowski@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14381/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      75393dbe
    • Mauro Carvalho Chehab's avatar
      cx231xx: fix GPIOs for Pixelview SBTVD hybrid · 9802f2db
      Mauro Carvalho Chehab authored
      commit 24b923f0 upstream.
      
      This device uses GPIOs: 28 to switch between analog and
      digital modes: on digital mode, it should be set to 1.
      
      The code that sets it on analog mode is OK, but it misses
      the logic that sets it on digital mode.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      9802f2db
    • Mauro Carvalho Chehab's avatar
      cx231xx: don't return error on success · 38cbcc78
      Mauro Carvalho Chehab authored
      commit 1871d718 upstream.
      
      The cx231xx_set_agc_analog_digital_mux_select() callers
      expect it to return 0 or an error. Returning a positive value
      makes the first attempt to switch between analog/digital to fail.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      38cbcc78
    • Mauro Carvalho Chehab's avatar
      mb86a20s: fix demod settings · e258efb3
      Mauro Carvalho Chehab authored
      commit 505a0ea7 upstream.
      
      With the current settings, only one channel locks properly.
      That's likely because, when this driver was written, Brazil
      were still using experimental transmissions.
      
      Change it to reproduce the settings used by the newer drivers.
      That makes it lock on other channels.
      
      Tested with both PixelView SBTVD Hybrid (cx231xx-based) and
      C3Tech Digital Duo HDTV/SDTV (em28xx-based) devices.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      e258efb3
    • Mauro Carvalho Chehab's avatar
      mb86a20s: fix the locking logic · d49f16e7
      Mauro Carvalho Chehab authored
      commit dafb65fb upstream.
      
      On this frontend, it takes a while to start output normal
      TS data. That only happens on state S9. On S8, the TS output
      is enabled, but it is not reliable enough.
      
      However, the zigzag loop is too fast to let it sync.
      
      As, on practical tests, the zigzag software loop doesn't
      seem to be helping, but just slowing down the tuning, let's
      switch to hardware algorithm, as the tuners used on such
      devices are capable of work with frequency drifts without
      any help from software.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      d49f16e7
    • Max Staudt's avatar
      fbdev/efifb: Fix 16 color palette entry calculation · e559b035
      Max Staudt authored
      commit d50b3f43 upstream.
      
      When using efifb with a 16-bit (5:6:5) visual, fbcon's text is rendered
      in the wrong colors - e.g. text gray (#aaaaaa) is rendered as green
      (#50bc50) and neighboring pixels have slightly different values
      (such as #50bc78).
      
      The reason is that fbcon loads its 16 color palette through
      efifb_setcolreg(), which in turn calculates a 32-bit value to write
      into memory for each palette index.
      Until now, this code could only handle 8-bit visuals and didn't mask
      overlapping values when ORing them.
      
      With this patch, fbcon displays the correct colors when a qemu VM is
      booted in 16-bit mode (in GRUB: "set gfxpayload=800x600x16").
      
      Fixes: 7c83172b ("x86_64 EFI boot support: EFI frame buffer driver")  # v2.6.24+
      Signed-off-by: default avatarMax Staudt <mstaudt@suse.de>
      Acked-By: default avatarPeter Jones <pjones@redhat.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      e559b035
    • Dan Carpenter's avatar
      scsi: zfcp: spin_lock_irqsave() is not nestable · 919b4765
      Dan Carpenter authored
      commit e7cb08e8 upstream.
      
      We accidentally overwrite the original saved value of "flags" so that we
      can't re-enable IRQs at the end of the function.  Presumably this
      function is mostly called with IRQs disabled or it would be obvious in
      testing.
      
      Fixes: aceeffbb ("zfcp: trace full payload of all SAN records (req,resp,iels)")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      919b4765
    • Steffen Maier's avatar
      zfcp: trace full payload of all SAN records (req,resp,iels) · 6f5790ba
      Steffen Maier authored
      commit aceeffbb upstream.
      
      This was lost with commit 2c55b750
      ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
      but is necessary for problem determination, e.g. to see the
      currently active zone set during automatic port scan.
      
      For the large GPN_FT response (4 pages), save space by not dumping
      any empty residual entries.
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: 2c55b750 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
      Reviewed-by: default avatarAlexey Ishchuk <aishchuk@linux.vnet.ibm.com>
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      6f5790ba
    • Steffen Maier's avatar
      zfcp: fix payload trace length for SAN request&response · 9e70e9ee
      Steffen Maier authored
      commit 94db3725 upstream.
      
      commit 2c55b750
      ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
      started to add FC_CT_HDR_LEN which made zfcp dump random data
      out of bounds for RSPN GS responses because u.rspn.rsp
      is the largest and last field in the union of struct zfcp_fc_req.
      Other request/response types only happened to stay within bounds
      due to the padding of the union or
      due to the trace capping of u.gspn.rsp to ZFCP_DBF_SAN_MAX_PAYLOAD.
      
      Timestamp      : ...
      Area           : SAN
      Subarea        : 00
      Level          : 1
      Exception      : -
      CPU id         : ..
      Caller         : ...
      Record id      : 2
      Tag            : fsscth2
      Request id     : 0x...
      Destination ID : 0x00fffffc
      Payload short  : 01000000 fc020000 80020000 00000000
                       xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx <===
                       00000000 00000000 00000000 00000000
      Payload length : 32                                  <===
      
      struct zfcp_fc_req {
          [0] struct zfcp_fsf_ct_els ct_els;
         [56] struct scatterlist sg_req;
         [96] struct scatterlist sg_rsp;
              union {
                  struct {req; rsp;} adisc;    SIZE: 28+28=   56
                  struct {req; rsp;} gid_pn;   SIZE: 24+20=   44
                  struct {rspsg; req;} gpn_ft; SIZE: 40*4+20=180
                  struct {req; rsp;} gspn;     SIZE: 20+273= 293
                  struct {req; rsp;} rspn;     SIZE: 277+16= 293
        [136] } u;
      }
      SIZE: 432
      Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
      Fixes: 2c55b750 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
      Reviewed-by: default avatarAlexey Ishchuk <aishchuk@linux.vnet.ibm.com>
      Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      9e70e9ee